7 ms·

Why the Linux kernel is hardly at risk

76 points by danieldk 15y ago

ghshephard 15y ago
My reading of this article is that Linus's machine is the real target if you want to inject malware into the kernel undetected.
- mstroeck 15y ago
  No - Linus' machine is still just another node. Git is fully distributed. Everything in that article still holds.
  - deleted 15y ago
    [deleted]
  - ori_b 15y ago
    Linus, however, is not distributed. If a malicious commit was discreetly slipped into his repository as a seemingly Linus-sourced change, there is enough trust in him that the change would likely propagate.
    - exDM69 15y ago
      Not without going through a quite extensive review process and then finally getting signed off (with a crypto signature) by several people. It's not entirely impossible but there are far more easier ways of getting malware out there.
      - gnosis 15y ago
        The ultimate goal might not be to simply get malware out there per se, but to discredit Linux's reputation as a secure OS. If that is the case, going to extra trouble to infect Linux kernel source may well be worth it for the attackers.
- dolbz 15y ago
  Really the point is that nothing can be injected into the git history undetected. To add any new code to the repository it needs to be put at the top of the 'stack' as the last commit. So even if someone got access to Linus' (or any other high level dev) machine they wouldn't be able to inject malware undetected as a look at recent commits would show the changes made.
  - kahawe 15y ago
    Yep, the very detailed article comes down to one basic fact: "we always have lots of copies on our and other people's machines so we can always track ANY possible modifications." In that regard, I guess it could be more "likely" to sneak in a very, very well hidden and cryptic exploit in contributed code.
    - lloeki 15y ago
      In reality such an exploit will be more likely to trigger both automated and human alarms in each different repo.
      - kahawe 15y ago
        Depending on how hidden and cryptic it is.
bsiemon 15y ago
I guess the best an attacker could hope for would be to modify the git binaries on the server. Even that would amount to little it seems.
- extension 15y ago
  If they could slip something into the git source then from there, they could tamper with any git project undetected. But since git is presumably self-hosted, it would still be profoundly difficult to get everyone to upgrade to the evil git without noticing the attack. It would require some devilishly underhanded code: http://underhanded.xcott.com/ http://underhanded.xcott.com/
  - tonfa 15y ago
    Given the number of changes coming in every release, and since some people rebase, a hash change might not be detected...
    - Xurinos 15y ago
      Speaking as a regular git user, I assure you that a hash change would be noticeable. Rebase would look for a common hash between your history and the remote history you just fetched and rebase your commits on top of it. When there is a mismatch, you experience a twilight zone where there are attempted merges of code that your changes had nothing to do with. At this point, it is apparent the remote history has changed, and in the process of trying to figure out how to rebase cleanly, your eyes will be on that foreign code. Given the number of changes coming in every release, more twilight zone experiences increases the number of eyes on the discrepancy. I am confident in the sanctity of the git-sourced code, thanks to there being multiple version of the same repository around that people are actively working on. I am more worried about all the stuff I might rely on that is not git-sourced.
      - tonfa 15y ago
        If the history is tampered during a rebase how would you notice? Suppose a tree well known for rebasing frequently is rebased on kernel.org, and the dev doing it works from the k.org servers (might be possible, since they give shell access). Then downstream would just see it as yet another rebase, no?
beza1e1 15y ago
The latest git SHA1 sum is not enough to check. The interesting part for intruders are "grafts": "Graft points or grafts enable two otherwise different lines of development to be joined together. It works by letting users record fake ancestry information for commits." https://git.wiki.kernel.org/index.php/GraftPoint https://git.wiki.kernel.org/index.php/GraftPoint Still easy to check though. ;)
- lloeki 15y ago
  IIRC grafts are local and not propagated by clone/push/fetch. Replacements via git-replace(1) are, though.
sneak 15y ago
What if they wanted to modify the source archives of some other project hosted there? Obviously the kernel is a big target, but it seems there are lots of other less-widespread things on there that would be useful to backdoor.
jbk 15y ago
A large portion of people and distributions take the kernel from tarballs, not from the git. So, this is very annoying for people who took kernels tarballs in the past from kernel.org. Sure, they can regenerate all the tarballs from the git repositories, but this isn't the point for the past actions.
- stygianguest 15y ago
  Perhaps this is a good opportunity to change that. Actually, I'd expect at least the bigger distributions to use git already. Git enables them to pick and choose from the updates and merge it with their own patches (alternative schedulers and the like). But you're right, as long as they serve tarballs, they should make sure they are safe. I've rolled some kernels myself and always used th e tarballs from kernel.org. Time to practice what I preach an rebuild from git.
- marbu 15y ago
  All tarbals are signed via linux kernel archives gpg key, which according to the kernel.org security breach announcement was not compromised. So I don't see a problem here.
  - recoiledsnake 15y ago
    Don't you see the problem with the server hosting both the tar balls and the signature being compromised?
    - bonzoesc 15y ago
      The signature can be validated with a public key not available on the server.
      - recoiledsnake 15y ago
        "can be' is different from 'is'. Since the attackers had root, what if they served up rootkitted kernels 1% of the time someone downloaded a tar ball?
andrewcooke 15y ago
this post assumes (if i have understood the argument correctly) SHA-1 is secure. it's isn't - it is well and truly broken. people don't use SHA-1 for security any more (well, they certainly shouldn't). is their any real analysis that shows that git is secure, given the weak nature of SHA-1? http://www.schneier.com/blog/archives/2005/02/sha1_broken.html http://www.schneier.com/blog/archives/2005/02/sha1_broken.ht...
- weavejester 15y ago
  It's not quite that simple. When cryptographic functions are broken, practical vulnerabilities are usually years away. A reduced SHA-1 collision time is certainly a good reason to move away from SHA-1, but it doesn't mean that an attacker can compromise an existing piece of code secured by a SHA-1 hash. In this case, it is not merely sufficient to find a collision, but to find a collision that is also a valid Git commit, implements a vulnerability, and, ideally, is not immediately obvious at first glance it is a hack (i.e. having kilobytes of garbage data in the commit diff). This is much harder than just finding a random set of bytes that just happens to match the commit SHA-1. Now, it could be that an organisation like the NSA is sufficiently ahead of public crypto technology that it is capable of not only finding a SHA-1 collision in feasible time, but is also able to craft a malicious Git commit with an identical SHA-1 to a legitimate commit. Inserting such a commit into the Linux source in an appropriate place might result in compromised kernels appearing in commercial products. But... I kinda doubt anyone is that far ahead, and in any case, it seems extremely risky to try to play such a high-value advantage in a public repository. If someone happens to spot your faked commit, suddenly everyone knows what you are capable of. So whilst Git would be more secure using SHA-512 or an equivalent, it's currently very unlikely that anyone has the practical capability and will to compromise the kernel's commit log.
  - andrewcooke 15y ago
    i am not saying git is insecure - i am saying someone needs to do exactly the analysis you are sketching. you can wave your hands and say that this is not a problem, but it's been 6 years since sha-1 was broken and that's an awfully long time. also, i find it absolutely typical of the place that HN has become that my original post asking a reasonable, informed question with reference is voted down. you're a bunch of mindless fucking morons.

76 points by danieldk 15y ago

My reading of this article is that Linus's machine is the real target if you want to inject malware into the kernel undetected.

mstroeck 15y ago
No - Linus' machine is still just another node. Git is fully distributed. Everything in that article still holds.
- deleted 15y ago
  [deleted]
- ori_b 15y ago
  Linus, however, is not distributed. If a malicious commit was discreetly slipped into his repository as a seemingly Linus-sourced change, there is enough trust in him that the change would likely propagate.
  - exDM69 15y ago
    Not without going through a quite extensive review process and then finally getting signed off (with a crypto signature) by several people. It's not entirely impossible but there are far more easier ways of getting malware out there.
    - gnosis 15y ago
      The ultimate goal might not be to simply get malware out there per se, but to discredit Linux's reputation as a secure OS. If that is the case, going to extra trouble to infect Linux kernel source may well be worth it for the attackers.
dolbz 15y ago
Really the point is that nothing can be injected into the git history undetected. To add any new code to the repository it needs to be put at the top of the 'stack' as the last commit. So even if someone got access to Linus' (or any other high level dev) machine they wouldn't be able to inject malware undetected as a look at recent commits would show the changes made.
- kahawe 15y ago
  Yep, the very detailed article comes down to one basic fact: "we always have lots of copies on our and other people's machines so we can always track ANY possible modifications." In that regard, I guess it could be more "likely" to sneak in a very, very well hidden and cryptic exploit in contributed code.
  - lloeki 15y ago
    In reality such an exploit will be more likely to trigger both automated and human alarms in each different repo.
    - kahawe 15y ago
      Depending on how hidden and cryptic it is.

bsiemon 15y ago

I guess the best an attacker could hope for would be to modify the git binaries on the server. Even that would amount to little it seems.

extension 15y ago
If they could slip something into the git source then from there, they could tamper with any git project undetected. But since git is presumably self-hosted, it would still be profoundly difficult to get everyone to upgrade to the evil git without noticing the attack. It would require some devilishly underhanded code: http://underhanded.xcott.com/ http://underhanded.xcott.com/
- tonfa 15y ago
  Given the number of changes coming in every release, and since some people rebase, a hash change might not be detected...
  - Xurinos 15y ago
    Speaking as a regular git user, I assure you that a hash change would be noticeable. Rebase would look for a common hash between your history and the remote history you just fetched and rebase your commits on top of it. When there is a mismatch, you experience a twilight zone where there are attempted merges of code that your changes had nothing to do with. At this point, it is apparent the remote history has changed, and in the process of trying to figure out how to rebase cleanly, your eyes will be on that foreign code. Given the number of changes coming in every release, more twilight zone experiences increases the number of eyes on the discrepancy. I am confident in the sanctity of the git-sourced code, thanks to there being multiple version of the same repository around that people are actively working on. I am more worried about all the stuff I might rely on that is not git-sourced.
    - tonfa 15y ago
      If the history is tampered during a rebase how would you notice? Suppose a tree well known for rebasing frequently is rebased on kernel.org, and the dev doing it works from the k.org servers (might be possible, since they give shell access). Then downstream would just see it as yet another rebase, no?

beza1e1 15y ago

The latest git SHA1 sum is not enough to check. The interesting part for intruders are "grafts": "Graft points or grafts enable two otherwise different lines of development to be joined together. It works by letting users record fake ancestry information for commits." https://git.wiki.kernel.org/index.php/GraftPoint https://git.wiki.kernel.org/index.php/GraftPoint Still easy to check though. ;)

lloeki 15y ago
IIRC grafts are local and not propagated by clone/push/fetch. Replacements via git-replace(1) are, though.

sneak 15y ago

What if they wanted to modify the source archives of some other project hosted there? Obviously the kernel is a big target, but it seems there are lots of other less-widespread things on there that would be useful to backdoor.

jbk 15y ago

A large portion of people and distributions take the kernel from tarballs, not from the git. So, this is very annoying for people who took kernels tarballs in the past from kernel.org. Sure, they can regenerate all the tarballs from the git repositories, but this isn't the point for the past actions.

stygianguest 15y ago
Perhaps this is a good opportunity to change that. Actually, I'd expect at least the bigger distributions to use git already. Git enables them to pick and choose from the updates and merge it with their own patches (alternative schedulers and the like). But you're right, as long as they serve tarballs, they should make sure they are safe. I've rolled some kernels myself and always used th e tarballs from kernel.org. Time to practice what I preach an rebuild from git.
marbu 15y ago
All tarbals are signed via linux kernel archives gpg key, which according to the kernel.org security breach announcement was not compromised. So I don't see a problem here.
- recoiledsnake 15y ago
  Don't you see the problem with the server hosting both the tar balls and the signature being compromised?
  - bonzoesc 15y ago
    The signature can be validated with a public key not available on the server.
    - recoiledsnake 15y ago
      "can be' is different from 'is'. Since the attackers had root, what if they served up rootkitted kernels 1% of the time someone downloaded a tar ball?

andrewcooke 15y ago

this post assumes (if i have understood the argument correctly) SHA-1 is secure. it's isn't - it is well and truly broken. people don't use SHA-1 for security any more (well, they certainly shouldn't). is their any real analysis that shows that git is secure, given the weak nature of SHA-1? http://www.schneier.com/blog/archives/2005/02/sha1_broken.html http://www.schneier.com/blog/archives/2005/02/sha1_broken.ht...

weavejester 15y ago
It's not quite that simple. When cryptographic functions are broken, practical vulnerabilities are usually years away. A reduced SHA-1 collision time is certainly a good reason to move away from SHA-1, but it doesn't mean that an attacker can compromise an existing piece of code secured by a SHA-1 hash. In this case, it is not merely sufficient to find a collision, but to find a collision that is also a valid Git commit, implements a vulnerability, and, ideally, is not immediately obvious at first glance it is a hack (i.e. having kilobytes of garbage data in the commit diff). This is much harder than just finding a random set of bytes that just happens to match the commit SHA-1. Now, it could be that an organisation like the NSA is sufficiently ahead of public crypto technology that it is capable of not only finding a SHA-1 collision in feasible time, but is also able to craft a malicious Git commit with an identical SHA-1 to a legitimate commit. Inserting such a commit into the Linux source in an appropriate place might result in compromised kernels appearing in commercial products. But... I kinda doubt anyone is that far ahead, and in any case, it seems extremely risky to try to play such a high-value advantage in a public repository. If someone happens to spot your faked commit, suddenly everyone knows what you are capable of. So whilst Git would be more secure using SHA-512 or an equivalent, it's currently very unlikely that anyone has the practical capability and will to compromise the kernel's commit log.
- andrewcooke 15y ago
  i am not saying git is insecure - i am saying someone needs to do exactly the analysis you are sketching. you can wave your hands and say that this is not a problem, but it's been 6 years since sha-1 was broken and that's an awfully long time. also, i find it absolutely typical of the place that HN has become that my original post asking a reasonable, informed question with reference is voted down. you're a bunch of mindless fucking morons.