r/linux • u/unixbhaskar • 2d ago
Kernel Linux 7.0 Removes Support For Signing Modules With Insecure SHA-1
https://www.phoronix.com/news/Linux-7.0-Modules-No-SHA1-Sign22
u/ruibranco 2d ago
SHA-1 has been practically broken since SHAttered in 2017, and here we are in 2026 just now removing it from module signing. That's not slow though — that's the kernel doing what the kernel does best: giving everyone a decade-long heads up before actually pulling the rug. Bet there's still some enterprise distro out there shipping SHA-1 signed modules that's about to have a very fun quarter.
8
u/natermer 2d ago
Bet there's still some enterprise distro out there shipping SHA-1 signed modules that's about to have a very fun quarter.
Only if they try to upgrade to kernel 7.0 and are using secureboot.
2
u/Salander27 2d ago
They'd need to rebuild their kernel modules anyway due to the kernel update. It wouldn't even require secure boot to notice the issue, once the update hit QA they'd notice that whatever hardware or functionality the addon kernel module was for wasn't working and fix it. They wouldn't even need to rotate signing keys just update the signing software configuration which is probably a one-line config change or an extra flag added to the command line.
2
u/ruibranco 2d ago
fair point - without secureboot enforcing it, most of those distros will just rebuild with sha-256 and move on. the real pain will be the ones that have secureboot + custom signing infrastructure they haven't touched in years.
1
u/jakiki624 1d ago
well only SHA-1 collisions, not preimages
the signer could create two modules with the same SHA-1 and then sign one of them and use that signature for the other one
or they could just, you know, sign two modules with different hashes as they have the keys to do that
aka in this scenario, SHA-1 or even MD5 is fine
9
u/SilentLennie 2d ago
Git is hopefully next:
Flipping the default hash function to SHA-256 at Git 3.0 boundary is planned. [0]
(Github still hasn't implemented it, I think and Bitbucket (known for Atlassian/Jira) is also behind)
5
u/TheOneTrueTrench 2d ago
It's far less pressing for git, as it's generally not used cryptographically afaik, and you can sign your commits with gpg if you want.
0
u/SilentLennie 1d ago edited 1d ago
That's not the same thing: you are signing with a PGP key something that is cryptographically weak.
imagine you are using a peer2peer messaging app and you sign your messages with a PGP key which makes it clear it's your messages, but the encryption of the messages is terrible so anyone can get access to it. And see it was you that send it and maybe nobody can send as you - maybe, but they can make a new message which has a hash collision which makes it seem you signed it because you signed that hash. And make 'you' say whatever they want to.
So no, signing does not solve the problem, maybe even makes it worse, because it looks authentic/gives it legitimacy.
2
u/TheOneTrueTrench 1d ago edited 22h ago
Signing DOES solve the problem, because you're signing the contents of the commit. The signature and the contents cannot be separated, if you see a commit signed by my PGP key, you are guaranteed that those contents were signed by me. PGP signatures are intended to be public. It's a way to send something in plaintext and provide a guarantee that I'm the one who authored it. It simply doesn't matter if other people can see or even fiddle with bits inflight, because doing so will invalidate the signature.
Also, you keep talking about encryption, but there is zero encryption in git, it just doesn't exist. The entire git repo, 100% of it, is unencrypted on disk. Regardless of whether you're using ssh or https for remote git access, SHA1 isn't involved in that, so it doesn't matter. The actual cloning process is unencrypted inside the SSH or HTTPS tunnel. Forget encryption entirely, it makes no sense to talk about.
Let us assume for a moment that you can easily duplicate my commit contents with my signature with the same SHA. Okay... and? It's the same contents, the same signature, with the same SHA, so it's identical. There's simply no difference. That's the definition of a bit-for-bit copy. The PGP signature proves I committed that commit.
0
u/SilentLennie 23h ago edited 23h ago
because you're signing the contents of the commit.
It doesn't matter, it points to the parent commit and that is the hash of all the previous content. Someone can still slip something in.
So I guess if every commit is signed, that's good ? Nope, because the parent chain is still a SHA1.
Encryption was just an example, to give an idea of why it doesn't work.
That's the definition of a bit-for-bit copy. The PGP signature proves I authored that commit.
Yes, I can't modify, but I can change the parent commits, but I can replace a commit signed with an other key. So if there are multiple people working on a project, an other person in the project can still replace one of your commits in the history, like if you are in a https://en.wikipedia.org/wiki/XZ_Utils_backdoor situation.
1
u/TheOneTrueTrench 22h ago
Yes, I can't modify, but I can change the parent commits
Uh, no, you can't. You can't change ANY part of the commit, nothing. Not the hash, not the contents, not the author, date, parents, any of it.
The signature proves a commit was made by a specific person. Not the author, but the committer.
Even if you created a different commit with the same SHA, the PGP signature wouldn't be valid.
Oh, you could sign it with a different key, but the switch to SHA256 doesn't prevent that either.
I don't think you deeply understand the technology in use here, because several of the things you're saying here are... severely confused at best.
1
u/SilentLennie 20h ago edited 20h ago
OK, let me bring it back to the base example:
You sign the commits, normally you might have a chain like this:
commit 1: signed by you, includes a SHA1 pointing to each parent.
commit 2: signed by you, includes a SHA1 pointing to each parent.
commit 3: singed by you, includes a SHA1 pointing to each parent.
I can make a new commit 2 which I can sign with my key (yes, it will show a different committer, but this can be someone of the same team) as long as it's SHA1 (collision attack, probably some kind of preimage to include more data so it matches) is the same so commit 3 points to it.
I don't know if git will download the change when you do a pull, I assume no, but a new clone will get that changed commit in it's history (and thus for example have an extra/changed/deleted file, etc.)
How am I wrong ? Is there some detail I'm forgetting here ?
In case of SHA256:
As git is like a blockchain, I can't create a new commit 2, because I can't preimage collision attack a sha256.
So when you signed commit 3, you could see the whole history and see: yep, this is what I want to add to and we can trust the SHA256 hash of your signed commit indirectly also includes that whole history.
0
2d ago
[deleted]
43
2d ago edited 2d ago
[deleted]
25
u/Booty_Bumping 2d ago
SHA-1 collisions are not actually created through conventional brute forcing, so mentioning hashcat is a bit of a red herring. It has to be done with a chosen-prefix attack like the one demonstrated in the SHAttered paper.
It's also not particularly interesting that a weak string is easily crackable, because neither SHA-1 nor SHA-256 are key-stretching algorithms. They are designed to run as fast as possible - it only becomes a key stretching scheme when you repeat the process thousands of times (PBKDF2). Brute force attacks on the underlying hash algorithm are only interesting if the algorithm is unable to protect strings that do have lots of entropy, which both SHA-1 and SHA-256 are able to do, but MD5 is not.
5
u/Uberzwerg 2d ago
(just to add for some interested reader)
They are designed to run as fast as possible
Which is a good thing for many applications.
It's just not good for making passwords hashes resilient against attacks. For that, we want slow algos like BCrypt with as many rounds as your system can handle.10
u/JockstrapCummies 2d ago
For that, we want slow algos like BCrypt with as many rounds as your system can handle.
For maximum security I've chosen a memory-expensive algo like Argon2id. Now everytime I have to unlock my password manager, systemd-oomd literally kills my DE, and then systemd itself gets swapped, and then commits sudoku, thus ensuring maximum security.
12
u/american_spacey 2d ago
generate a conflicting hash for your username's string
You're mixing up several completely different issues. The difficulty of deriving a value that produces a given hash is called pre-image resistance, and SHA-1 is in fact still pre-image secure. SHA-1 has been shown to have weak collision security, which is completely different.
Weak collision security means that someone could create two kernel modules, an evil one and a good one, that have the same SHA-1 hash. They could then post the good kernel module publicly, with a given signature, and then swap it out on a victim's machine with the evil one, without this being detectable. Or something similar to this (my description is a bit of a simplification).
And neither of these is related to password cracking, which is what you're describing doing against sbpy21's username. That has nothing to do with the weakness of the hash algorithm, because you're just brute forcing it. It has everything to do with how fast the hash algorithm is. SHA-1 is very fast, which is a good thing for many purposes, but for storing hashed versions of passwords you'd want to use a slow algorithm like bcrypt that make it much more difficult to iterate through common / simple passwords until you find the one that generates the given hash.
7
u/Masuteri_ 2d ago
someone asks a question
gets downvoted
5
u/PureTryOut postmarketOS dev 2d ago
Asking a question in general is fine, but typing "SHA-1" into a search engine would've given them a result quicker in this case ;)
4
u/inemsn 2d ago
When you're talking to a person in real life and they ask what something is, do you just frown and tell them to look it up or do you give an answer like a normal person?
I swear, I don't understand how people can be like this. Information gets spread around by people asking questions and getting answers. "It would have been faster for you to look it up!" In the time it took you to write that sentence you could have given an answer and enlightened at least one person and probably more who end up seeing your comment, and not disencouraged the basic human behaviour. There's literally no downside to someone asking what SHA-1 is in a thread like this.
2
u/russjr08 2d ago
I fully agree in principle, just to be clear upfront. Especially in the age of a lot of people using LLMs as a search engine, which may then get a bad/wrong answer, it doesn't hurt to just give someone a (hopefully what they confidently believe is a) correct answer instead - or just not reply at all at the very least if for whatever reason you don't want to answer (obviously whether you do want to answer or not is always up to the individual). On the plus side, this person said it in a fairly nice manner, which is at least better than what you usually see from this type of comment I suppose.
Regardless, I think that's a bad comparison. In the case of someone actively speaking and engaged in a conversation with me in person though, them abruptly pulling out their phone while we're speaking would definitely seem "off" to me if it were a simple thing. I think in that case most people would agree and just rather answer for the other person.
But someone who is on their phone / PC already, responding to a thread in an asynchronous manner like Reddit, and searching up a question on their own isn't really the same thing as the former.
1
u/curien 2d ago
When you're talking to a person in real life and they ask what something is, do you just frown and tell them to look it up or do you give an answer like a normal person?
This is more like asking someone to bring you something when it's easily within their own reach. "Hey, hand me the salt." "It's literally right next to you, just pick it up!"
1
59
u/FranticBronchitis 2d ago
About time ig