Workaround for the GSM privilege escalation vulnerability

2024-04-12 Thread Stephan Verbücheln
Hello everyone

At the moment, there are reports about unfixed privilege escalation
vulnerabilities in the GSM kernel module (n_gsm) in the tech news. This
kernel module is shipped with Debian by default.
Two security researchers both claim credit for their discovery[1][2].
Neither researcher do not name any CVE numbers. The Openwall discussion
names several CVE numbers: CVE-2023-6546 and VE-2023-52564. It is not
clear to me whether it is one or multiple vulnerabilities.
However, many Linux users and admins are worrying but cannot find
workarounds or recommendations from a trusted source. A proposed fix
was published, but has already been called ineffective by security
researchers[3].

After some research and discussion with Moritz Mühlenhoff, I believe it
is sufficient to blacklist[4] the n_gsm module. To achieve this, create
a file /etc/modprobe.d/n_gsm.conf with the following content:

blacklist n_gsm
install n_gsm /bin/true

For anyone who do not use GSM on their server or workstation, this
probably does not have any downsides.

Best regards
Stephan

[1] https://github.com/YuriiCrimson/ExploitGSM
[2] https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html
[3] https://www.openwall.com/lists/oss-security/2024/04/12/1
[4] https://wiki.debian.org/KernelModuleBlacklisting


signature.asc
Description: This is a digitally signed message part


Re: Reaction to potential PGP schism

2023-12-21 Thread Stephan Verbücheln
Interesting point in this talk: The APT team is already working on non-
PGP signatures.

https://wiki.debian.org/Teams/Apt/Spec/AptSign

I can see the advantages of that for release signatures which use a
rarely changing set of keys.
However, I do not see any good alternative for PGP for personal
signatures such as developer communication and maintainer uploads. PGP
is really handy because once trust of the key fingerprint for a person
is established, the person can easily make changes such as adding
subkeys, editing the expiration date, revoking keys, etc. at any time.

This would also be less convenient with a CMS-PKI-CA-hierarchy based
system.

Regards
Stephan


signature.asc
Description: This is a digitally signed message part


Reaction to potential PGP schism

2023-12-14 Thread Stephan Verbücheln
Hello everyone

As you probably know, Debian relies heavily on GnuPG for various
purposes, including:
- developer communication
- signing of tarballs and patches
- automated processes such as update validation by APT

The OpenPGP Working Group at IETF is currently working on a new
standard.

https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/

Due to different opinions, some people (including notably the GnuPG
team) have quit the IETF Working Group and proposed their own LibrePGP
standard.

https://librepgp.org/

Notably remaining in the IETF Working Group are people from Proton Mail
(maintaining OpenPGP.JS) and Sequoia PGP (free implementation in Rust).

The disagreements are about details such as algorithms and file formats
which make both standards incompatible.

How can Debian deal with this? Should Debian intervene to prevent the
worst?

Regards
Stephan



signature.asc
Description: This is a digitally signed message part


Re: Concerns about Security of packages in Debain OS and the Operating system itself.

2022-04-18 Thread Stephan Verbücheln
> i did the analysis (took 3 weeks)

Do you have a publication of that analysis? I was thinking the same
about the organization of Debian for some time but never did analysis
or compared it to other distros.

Also I like to add that reproducible builds are an excellent addition
to the mechanisms you are describing.

Regards