Almost all our laptops, and many servers, feature a TPM today. The TPM doesn't have the best reputation in the community because it could be used to lock down platforms or do nasty things with DRM. Under normal conditions on PCs, the TPM is controlled by the system owner and could actually be useful for almost anything involving crypto. Unfortunately the integration of the TPM in the OS is essentially non-existent. The introduction of the TPM2.0 standard complicates matters, because we now have two different devices with different APIs.

The goal of this project would be to identify reasonable use cases for the TPM, evaluate exisiting projects, and create ways how to integrate it into various workflows in openSUSE.

Looking for hackers with the skills:

cryptography security

This project is part of:

Hack Week 15

Activity

  • about 8 years ago: randybb liked this project.
  • about 8 years ago: hennevogel liked this project.
  • about 8 years ago: mwilck liked this project.
  • about 8 years ago: mwilck added keyword "cryptography" to this project.
  • about 8 years ago: mwilck added keyword "security" to this project.
  • about 8 years ago: mwilck originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    Migrate from Docker to Podman by tjyrinki_suse

    Description

    I'd like to continue my former work on containerization of several domains on a single server by changing from Docker containers to Podman containers. That will need an OS upgrade as well as Podman is not available in that old server version.

    Goals

    • Update OS.
    • Migrate from Docker to Podman.
    • Keep everything functional, including the existing "meanwhile done" additional Docker container that is actually being used already.
    • Keep everything at least as secure as currently. One of the reasons of having the containers is to isolate risks related to services open to public Internet.
    • Try to enable the Podman use in production.
    • At minimum, learn about all of these topics.
    • Optionally, improve Ansible side of things as well...

    Resources

    A search engine is one's friend. Migrating from Docker to Podman, and from docker-compose to podman-compose.


    OIDC Loginproxy by toe

    Description

    Reverse proxies can be a useful option to separate authentication logic from application logic. SUSE and openSUSE use "loginproxies" as an authentication layer in front of several services.

    Currently, loginproxies exist which support LDAP authentication or SAML authentication.

    Goals

    The goal of this Hack Week project is, to create another loginproxy which supports OpenID Connect authentication which can then act as a drop-in replacement for the existing LDAP or SAML loginproxies.

    Testing is intended to focus on the integration with OIDC IDPs from Okta, KanIDM and Authentik.

    Resources


    Bot to identify reserved data leak in local files or when publishing on remote repository by mdati

    Description

    Scope here is to prevent reserved data or generally "unwanted", to be pushed and saved on a public repository, i.e. on Github, causing disclosure or leaking of reserved informations.

    The above definition of reserved or "unwanted" may vary, depending on the context: sometime secret keys or password are stored in data or configuration files or hardcoded in source code and depending on the scope of the archive or the level of security, it can be either wanted, permitted or not at all.

    As main target here, secrets will be registration keys or passwords, to be detected and managed locally or in a C.I. pipeline.

    Goals

    • Detection:

      • Local detection: detect secret words present in local files;
      • Remote detection: detect secrets in files, in pipelines, going to be transferred on a remote repository, i.e. via git push;
    • Reporting:

      • report the result of detection on stderr and/or log files, noticed excluding the secret values.
    • Acton:

      • Manage the detection, by either deleting or masking the impacted code or deleting/moving the file itself or simply notify it.

    Resources

    • Project repository, published on Github (link): m-dati/hkwk24;
    • Reference folder: hkwk24/chksecret;
    • First pull request (link): PR#1;
    • Second PR, for improvements: PR#2;
    • README.md and TESTS.md documentation files available in the repo root;
    • Test subproject repository, for testing CI on push [TBD].

    Notes

    We use here some examples of secret words, that still can be improved.
    The various patterns to match desired reserved words are written in a separated module, to be on demand updated or customized.

    [Legend: TBD = to be done]


    Contributing to Linux Kernel security by pperego

    Description

    A couple of weeks ago, I found this blog post by Gustavo Silva, a Linux Kernel contributor.

    I always strived to start again into hacking the Linux Kernel, so I asked Coverity scan dashboard access and I want to contribute to Linux Kernel by fixing some minor issues.

    I want also to create a Linux Kernel fuzzing lab using qemu and syzkaller

    Goals

    1. Fix at least 2 security bugs
    2. Create the fuzzing lab and having it running

    The story so far

    • Day 1: setting up a virtual machine for kernel development using Tumbleweed. Reading a lot of documentation, taking confidence with Coverity dashboard and with procedures to submit a kernel patch
    • Day 2: I read really a lot of documentation and I triaged some findings on Coverity SAST dashboard. I have to confirm that SAST tool are great false positives generator, even for low hanging fruits.
    • Day 3: Working on trivial changes after I read this blog post: https://www.toblux.com/posts/2024/02/linux-kernel-patches.html. I have to take confidence with the patch preparation and submit process yet.
      • First trivial patch sent: using strtruefalse() macro instead of hard-coded strings in a staging driver for a lcd display
      • Fix for a dereference before null check issue discovered by Coverity (CID 1601566) https://scan7.scan.coverity.com/#/project-view/52110/11354?selectedIssue=1601566
    • Day 4: Triaging more issues found by Coverity.
      • The patch for CID 1601566 was refused. The check against the NULL pointer was pointless so I prepared a version 2 of the patch removing the check.
      • Fixed another dereference before NULL check in iwlmvmparsewowlaninfo_notif() routine (CID 1601547). This one was already submitted by another kernel hacker :(
    • Day 5: Wrapping up. I had to do some minor rework on patch for CID 1601566. I found a stalker bothering me in private emails and people I interacted with me, advised he is a well known bothering person. Markus Elfring for the record.
    • Wrapping up: being back doing kernel hacking is amazing and I don't want to stop it. My battery pack is completely drained but changing the scope gave me a great twist and I really want to feel this energy not doing a single task for months.

      I failed in setting up a fuzzing lab but I was too optimistic for the patch submission process.

    The patches

    1


    VulnHeap by r1chard-lyu

    Description

    The VulnHeap project is dedicated to the in-depth analysis and exploitation of vulnerabilities within heap memory management. It focuses on understanding the intricate workflow of heap allocation, chunk structures, and bin management, which are essential to identifying and mitigating security risks.

    Goals

    • Familiarize with heap
      • Heap workflow
      • Chunk and bin structure
      • Vulnerabilities
    • Vulnerability
      • Use after free (UAF)
      • Heap overflow
      • Double free
    • Use Docker to create a vulnerable environment and apply techniques to exploit it

    Resources

    • https://heap-exploitation.dhavalkapil.com/divingintoglibc_heap
    • https://raw.githubusercontent.com/cloudburst/libheap/master/heap.png
    • https://github.com/shellphish/how2heap?tab=readme-ov-file