Model checking the BPF verifier by shunghsiyu

Project Description

BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).

One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.

For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.

Goal for this Hackweek

Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.

Resources

• Formal Methods for the Informal Engineer: Tutorial #1 - The Z3 Theorem Prover and its accompanying notebook is a great introduction into Z3
  • Has a section specifically on model checking
• Software Verification and Analysis Using Z3 a great example of using Z3 for model checking
• Sound, Precise, and Fast Abstract Interpretation with Tristate Numbers - existing work that use formal verification to prove that the multiplication helper used for value tracking work as intended
• [PATCH v5 net-next 00/12] bpf: rewrite value tracking in verifier - initial patch set that adds tristate number to the verifier

---

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

---

CVE portal for SUSE Rancher products by gmacedo

Description

Currently it's a bit difficult for users to quickly see the list of CVEs affecting images in Rancher, RKE2, Harvester and Longhorn releases. Users need to individually look for each CVE in the SUSE CVE database page - https://www.suse.com/security/cve/ . This is not optimal, because those CVE pages are a bit hard to read and contain data for all SLE and BCI products too, making it difficult to easily see only the CVEs affecting the latest release of Rancher, for example. We understand that certain costumers are only looking for CVE data for Rancher and not SLE or BCI.

Goals

The objective is to create a simple to read and navigate page that contains only CVE data related to Rancher, RKE2, Harvester and Longhorn, where it's easy to search by a CVE ID, an image name or a release version. The page should also provide the raw data as an exportable CSV file.

It must be an MVP with the minimal amount of effort/time invested, but still providing great value to our users and saving the wasted time that the Rancher Security team needs to spend by manually sharing such data. It might not be long lived, as it can be replaced in 2-3 years with a better SUSE wide solution.

Resources

• The page must be simple and easy to read.
• The UI/UX must be as straightforward as possible with minimal visual noise.
• The content must be created automatically from the raw data that we already have internally.
• It must be updated automatically on a daily basis and on ad-hoc runs (when needed).
• The CVE status must be aligned with VEX.
• The raw data must be exportable as CSV file.
• Ideally it will be written in Go or pure Shell script with basic HTML and no external dependencies in CSS or JS.

---

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]

---

Kanidm: A safe and modern IDM system by firstyear

Kanidm is an IDM system written in Rust for modern systems authentication. The github repo has a detailed "getting started" on the readme.

Kanidm Github

In addition Kanidm has spawn a number of adjacent projects in the Rust ecosystem such as LDAP, Kerberos, Webauthn, and cryptography libraries.

In this hack week, we'll be working on Quokca, a certificate authority that supports PKCS11/TPM storage of keys, issuance of PIV certificates, and ACME without the feature gatekeeping implemented by other CA's like smallstep.

For anyone who wants to participate in Kanidm, we have documentation and developer guides which can help.

I'm happy to help and share more, so please get in touch!

---

Model checking the BPF verifier by shunghsiyu

Project Description

BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).

One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.

For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.

Goal for this Hackweek

Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.

Resources

• Formal Methods for the Informal Engineer: Tutorial #1 - The Z3 Theorem Prover and its accompanying notebook is a great introduction into Z3
  • Has a section specifically on model checking
• Software Verification and Analysis Using Z3 a great example of using Z3 for model checking
• Sound, Precise, and Fast Abstract Interpretation with Tristate Numbers - existing work that use formal verification to prove that the multiplication helper used for value tracking work as intended
• [PATCH v5 net-next 00/12] bpf: rewrite value tracking in verifier - initial patch set that adds tristate number to the verifier

---

FizzBuzz OS by mssola

Project Description

FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).

This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.

This project is free software and you can find it here.

Goal for this Hackweek

• Better understand the RISC-V SBI interface.
• Better understand RISC-V in privileged mode.
• Have fun.

Resources

• SBI v2.0 ratified specification
• Blog post on SBI
• mssola/fbos

Results

The project was a resounding success Lots of learning, and the initial target was met.

---

Modularization and Modernization of cifs.ko for Enhanced SMB Protocol Support by hcarvalho

Creator:
Enzo Matsumiya ematsumiya@suse.de @ SUSE Samba team
Members:
Henrique Carvalho henrique.carvalho@suse.com @ SUSE Samba team

Description

Split cifs.ko in 2 separate modules; one for SMB 1.0 and 2.0.x, and another for SMB 2.1, 3.0, and 3.1.1.

Goals

Primary

Start phasing out/deprecation of older SMB versions

Secondary

• Clean up of the code (with focus on the newer versions)
• Update cifs-utils
• Update documentation
• Improve backport workflow (see below)

Technical details

Ideas for the implementation.

• fs/smb/client/{old,new}.c to generate the respective modules
  • Maybe don't create separate folders? (re-evaluate as things progresses!)
• Remove server->{ops,vals} if possible
• Clean up fs_context.* -- merge duplicate options into one, handle them in userspace utils
• Reduce code in smb2pdu.c -- tons of functions with very similar init/setup -> send/recv -> handle/free flow
• Restructure multichannel
  • Treat initial connection as "channel 0" regardless of multichannel enabled/negotiated status, proceed with extra channels accordingly
  • Extra channel just point to "channel 0" as the primary server, no need to allocate an extra TCPServerInfo for each one
• Authentication mechanisms
  • Modernize algorithms (references: himmelblau, IAKERB/Local KDC, SCRAM, oauth2 (Azure), etc.

---

Linux on Cavium CN23XX cards by tsbogend

Before Cavium switched to ARM64 CPUs they developed quite powerful MIPS based SOCs. The current upstream Linux kernel already supports some Octeon SOCs, but not the latest versions. Goal of this Hack Week project is to use the latest Cavium SDK to update the Linux kernel code to let it running on CN23XX network cards.

---

Kill DMA and DMA32 memory zones by ptesarik

Description

Provide a better allocator for DMA-capable buffers, making the DMA and DMA32 zones obsolete.

Goals

Make a PoC kernel which can boot a x86 VM and a Raspberry Pi (because early RPi4 boards have some of the weirdest DMA constraints).

Resources

• LPC2024 talk:
• video:

---