Kernel.org Compromised 312
First time accepted submitter JoeF writes "There is a note posted on the main kernel.org page indicating that kernel.org was compromised earlier this month: 'Earlier this month, a number of servers in the kernel.org infrastructure were compromised. We discovered this August 28th. While we currently believe that the source code repositories were unaffected, we are in the process of verifying this and taking steps to enhance security across the kernel.org infrastructure.' The note goes on to say that it is unlikely to have affected the source code repositories, due to the nature of git."
Wishful thinking (Score:2, Insightful)
Re:Wishful thinking (Score:5, Insightful)
And seriously, why else would you hack kernel.org?
Re:Wishful thinking (Score:5, Insightful)
1337 points.
Re: (Score:2)
Re: (Score:2)
but if the repos are still good - then it should be easy to trace any changes/modifications to the other distribution channels - and update/inform the people who use them
Re: (Score:2)
Ahem. i did not leave my email there to notify me the last time i downloaded the tarball
Re: (Score:2)
Ahem. i did not leave my email there to notify me the last time i downloaded the tarball
...why anonymous ftp and leaving your email address in the password field can be a good thing. Not that anyone does that anymore.
The main point is, it won't take a line by line audit to look for malicious code, rather just working with the crypto to verify a chain of trust.
Re: (Score:3, Insightful)
Are you stupid?
The files are in a git repository. That's what matters, not what you wrap around it to provide for requests. Anyone who happened to have a local git copy will notice VERY QUICKLY what changed when they try to commit... and I'd venture to say that nearly all of the kernel developers Who Matter use git for their development workflow.
he's talking about tarballs (Score:5, Insightful)
The files are in a git repository. That's what matters, not what you wrap around it to provide for requests.
So http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.4.tar.bz2 [kernel.org] gets pulled dynamically from git?
the kernel developers Who Matter
Are you saying users don't?
Re: (Score:2)
It's about the commit (Score:3)
You Download source code from a tarball at kernel.org. You develop against that. You commit to git. You change only 3 files and git tells you there are 20 files changed. This is when you realize that somehow, the tarball differs in 17 files from the git repository.
How many developers actually develop against a freshly downloaded tarball off ftp/http kernel.org mirror, in stead of a checkout/sync from the clean git branch? Because only the ones that do, and also have commit
Re: (Score:2)
The hash isn't automagic, it's produced and provided by the distributor of the code or binary. A hash won't protect you if the source of the hash has been hacked. Sure I can download a kernel tar from a mirror and then check kernel.org for the hash, but where do you go to validate that kernel.org is real. A clever hacker in 17 days, could very easily replace the kernel tar balls and their associated hashes and the only way anyone would know would be if someone happened to have a reference of what that key h
Re: (Score:2)
A really well hidden back door would either consist of introducing a security breach, or exposing api's not normally found in that section of the code. Either way, it'll be found especially now that it is under scrutiny.
There are so many copies of the kernel sitting on thousands of different unrelated servers around the world, not to mention peoples personal backups. Anything changed can and will be found easily.
Re: (Score:2)
Now that they know, yes, it will probably be found. That doesn't mean that 1) tarballs weren't infected and 2) that changes weren't made to the code and approved because someone was impersonating a trusted developer. It will be resolved, but it could also easily have created a problem which may take months to fully work itself out.
Re:he's talking about tarballs (Score:4, Insightful)
%Y-%m-%d please! Americans...
Re: (Score:2)
Yeah, like I need to be reminded what year it is on a daily basis.
Re:he's talking about tarballs (Score:4)
Need I point out that %Y-%m-%d sorts properly, whereas %m-%d-%Y does not? When's the last time you needed releases sorted by month but not year?
Re: (Score:2)
Ok so that makes sense. I'm used to seeing releases sorted by version numbers though, I don't go for snapshots very often.
Re: (Score:2)
Actually I think I might take back what I said. I like version numbers, and don't see why you would need to have several years worth of snapshots in the same directory. That sounds like a ridiculous waste of space that nobody will ever need to go through(assuming you manage to ever finish something). Past few months worth of snapshots can be worth keeping around.
So there! Americans Rule again :)
YMD sorts (Score:5, Insightful)
Yeah, like I need to be reminded what year it is on a daily basis.
Actually YMD is useful because it sorts.
Re: (Score:2)
Actually, i think you are wrong. As far as i understand the repository is not checked during a commit. Edit directly in the repository and your modification will only be uncovered by git-fsck AFAIU.
Re: (Score:2)
Oh.
Well. You DO check the signatures right? Those are there for a reason...
Re: (Score:2)
They don't exactly go out of their way to draw attention to the fact that the signatures even exist, do they? The mention of signing is after the paragraphs of recent news, which most users are not likely looking at when they go to download the file. The .sign file is hidden in the file structure, no link on the main page.
The fact that they provide a nice, bold link to the current version without even a smaller link to its corresponding signature is a pretty big oversight. Even basic projects generally prov
Re: (Score:2)
Check signatures against what? kernel.org? the one that was hacked?
Or your package manager (.ebuild or whatever)? the one that might have been made while a "patched" tarball was already up, and contains the matching hash?
(for the record, I think it's highly unlikely, but all distros should definitely audit their kernel packages to see what they built them from)
Re:Wishful thinking (Score:4, Insightful)
If the attackers were worth their salt, after gaining access they would drop in their own custom replacements for patch, make and gcc. For such a large code base, it is not easy to tell if the code going in is yielding the expected instructions.
Re:Wishful thinking (Score:5, Informative)
If the attackers were worth their salt, after gaining access they would drop in their own custom replacements for patch, make and gcc.
Since patch, make, and gcc are all GNU tools and not part of the Linux kernel, the only harm would be to the single copy on the kernel.org machine. If that machine isn't part of the build process (i.e., if it was merely a file repository), then nothing would be compromised.
It would also be pretty easy to see because builds from other machines wouldn't match.
Re: (Score:3)
It would also be pretty easy to see because builds from other machines wouldn't match.
Would it? I'm wondering because in all my life, downloading and compiling stuff, I've never compared a binary with one compiled on a different machine to see if it matched. Maybe someone would, which is why I am asking. Are there people who commonly do that? Why?
Re: (Score:2)
Since patch, make, and gcc are all GNU tools and not part of the Linux kernel
It's not exactly hard to make a kernel that would specifically check for loading of those processes, and patch them up on the fly to make them behave as it needs.
Re:Wishful thinking (Score:5, Interesting)
You know what? Linux users will go right on using plain Linux. Not SE Linux, not OpenBSD, and certainly not Windows. We're not even going to change our root passwords. Why? Because this security breach is not that big a deal.
Yes, it is embarrassing for kernel.org, but the damage is not that great. Sure, we'd all like to prevent security breaches from ever happening in the first place, but I have always thought detection and recovery is more important than prevention. Kernel.org has that covered in spades. Keep backups. Keep many backups. Keep them in many different locations. A distributed source code revision control system such as git does that automatically. Whoever did this wasn't too smart if they were seriously trying to inject a backdoor into the Linux kernel. Now they've blown their cover. They can't have seriously expected the code modifications they tried to go unnoticed for long, unless they have no idea how large projects handle source code. So either they were dumb, or all they were trying to do was embarrass Linux.
Re: (Score:2)
You know what? Linux users will go right on using plain Linux. Not SE Linux, not OpenBSD, and certainly not Windows.
Maybe the Ubuntu users. Myself, I like a kernel enhanced [wikipedia.org] with capabilities [wikipedia.org]. It saved my butt once from the bugs the mighty kernel developers introduce ever so often in the kernel, with their "release early, release often" philosophy (we see now where that leads with this incident).
You don't git it (Score:3, Informative)
Not need to panic. Yet. Most users don't download their kernels from kernel.org. This is a fact. Most users download via the package repositories of their favorite Linux distro, say Ubuntu or Arch. And the ke
Re: (Score:2)
Do admins get more hardcore than that administer key servers like Kernel.org's, RedHat's, Debian's ?
Yeah, they do. Such as Open Wall Linux [openwall.com] Project, spearheaded by one Solar Designer.
Oops (Score:5, Insightful)
This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.
Re:Oops (Score:5, Insightful)
If the same thing happened to Microsoft, Microsoft wouldn't let anybody know.
Re: (Score:2)
But anybody would let MS know.
Re:Oops (Score:5, Funny)
This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.
Nah. They wouldn't bash them. cmd them, maybe. But not bash them.
Re: (Score:2, Insightful)
>but this is no different than Windows, despite the FUD.
>no different than windows.
THIS IS WHAT WINDOWS FANBOIS REALLY BELIEVE.
Get back to me when Windows separates execute permission from the filename extension.
--
BMO
Re: (Score:2, Funny)
Get back to me when Windows separates execute permission from the filename extension.
I sent you that e-mail 15 years ago. You should check your spam filter.
Re: (Score:2)
Hey buddy, 1995 called, they wanted their antiquated filesystems back. NTFS has supported seperate "execute" permissions since its inception, I believe. In fact, call me when ext3 seperates its "write" permission from its "change permissions / take ownership" permission.
Re: (Score:3)
Hey buddy, 1995 called, they wanted their antiquated filesystems back. NTFS has supported seperate "execute" permissions since its inception, I believe. In fact, call me when ext3 seperates its "write" permission from its "change permissions / take ownership" permission.
True, the NTFS filesystem supports finer grained permissions and some features that are simply not used or exposed in windows. Generally read/execute are grouped together and trying to set them differently often breaks things. The usual case for windows is that if you can read the file, you can execute it.
Linux has a great mounting option called noexec, which is very handy to apply to the home partition. Ext3 has some extensions to provide finer grained permissions and features (eg chattr), but it's not
Re: (Score:2)
Generally read/execute are grouped together and trying to set them differently often breaks things. The usual case for windows is that if you can read the file, you can execute it
Its true you have to dig a little bit to get to the execute permission (under advanced permissions), but I have used them before for the purposes of making network shares non-infectable (virus may hide there, but it sure as heck wont run).
Ive not run into an issue where read-but-not-execute has broken something, other than executable content that obviously refused to run.
Linux has a great mounting option called noexec, which is very handy to apply to the home partition.
I am aware of it, though as I do not administer any linux workstations I have never had the opportunity to use it. It certainly is a nice
Re: (Score:2)
I am aware that they are seperate, but for all intents and purposes having one is having the other. If you can take ownership of a file, you can change its permissions however you want, and if you can change permissions, you can grant yourself "take ownership". There may be a corner case where there is some difference, but I have never encountered it.
Also, have you ever heard of ext2/3's extended attributes
I had not; I have heard of the extended ACLs (which appear to be a kludge). Howeve, according to wikipedia, extended attributes are not a filesystem feature
Re: (Score:2)
Above post should have read
extended attributes are not a filesystem security feature, but metadata.
It made sense in my head when I typed it, but obviously it didnt translate so well to a post.
Re: (Score:3)
Re: (Score:2)
Windows just sees the .exe and says "whoopee, we can execute it!"
BZZZT Wrong, try again.
NTFS has a specific "execute" permission; additionally, it uses alternate data streams to block execution of any executable code downloaded from the internet. Finally, GPOs can easily block code execution based on file signature, location, or publisher.
Care to try again?
Re: (Score:3)
Again, it doesn't bloody matter because that doesn't fucking happen in reality.
BZZZZT Wrong again.
By default downloaded content-- I believe all of it-- is marked with an ADS flag, and requires approval before launching.
Additionally, I DO have a number of clients where I have restricted where executable content can come from, and I did it in about 5 minutes without having to dick around with chmods, or scripting chmods, or figuring out how to prevent them from changing the acl while still having write access to the file.
See, in EXT3, unless im mistaken, you cannot give a user write acc
Re: (Score:2)
It IS present in XP, and has been probably since SP2. As you said, bmo doesnt have a clue.
Re: (Score:3)
Second: On Windows it's really hard to disallow users to run any programs but the ones in C:\Windows and C:\Program Files while it's trivially easy in UNIX-like systems.
Ahem.
Start | Administrative tools | Local Security Policy | Software Restriction Policies | New Software Restriction Policy
Was that hard? Btw, an administrator can configure this in a group policy and apply it to select users, groups, computer sets etc. The above was a local policy.
Now you have a policy which by default allows only programs to execute from "program files" and "windows"
You can configure much more, like e.g. whether executables on a given path should be allowed to execute with admin privilege
Re: (Score:3)
So I have to run AD locally to be able to disallow users to run arbitrary files? Brilliant! Let's f** home users, like we care.
No, that is what Local Security Policy is for. When in a domain, domain GPO takes preference if there are conflicts. But as a home user you can simply use the LSP.
Re: (Score:2)
Windows just sees the .exe and says "whoopee, we can execute it!"
Nahh come on be fair! Windows can execute a lot of stuff that isn't .exe too.
Re: (Score:2)
I have never seen a windows box in my entire life that would not execute a file with .exe on the end of it. There very Well may be a way to change this behavior but for all intents and purposes, it may as well not exist. Maybe the next time my friend's machine gets hosed by the Trojan du jour I'll ask him if he "had the execute permissions which is assigned to users based on the perms on the file" set right. I mean, surely that is the default, right?
Re: (Score:3)
By default, precisely dick. If you Windows guys get to pretend that NTFS execute permissions are commonly used, we Linux guys get to pretend that people commonly set /home and /tmp noexec and use SELinux. Deal?
Re: (Score:2)
Has existed since Windows XP SP2.
Files can have a Zone Identifier applied to them via NTFS alternate data streams.
The Zone Identifier can restrict execution, causing a popup to confirm if the user really wants to execute it.
Wouldn't be that hard to extend that so that it outright blocks execution without asking the user.
The zone identifier is only added in some instances, and it only give a general idea of where the file came from . It is a poor security mechanism at best. It requires having an NTFS file system. It requires the program running it to read and honor that information. There are ways of getting around this.
Please educate yourself on Windows (Score:3)
Doesn't fucking matter, because theory is not practice.
Windows assigns execute permission based on the last 3 letters by default. It's up to the administrator to change this behavior, which hardly ever happens.
In the world of real computers, execute bits are *completely independent* of the name.
Oh please.
The .exe association is merely a convenience, not a security mechanism which "assigns execute permission" as you put it. It is equivalent to how Linux will attempt to run *anything* when you type the name or double-click it. It is a launching mechanism, not a security mechanism.
Yes, Linux has the x bit. Guess what, Windows ACLs has the Traverse/Execute permission. Remove that permission or set up a deny rule and you will not be able to execute that file or files in that directory. Want to ensure t
Re:Oops (Score:5, Insightful)
Ok... I'll bite.... I will concede that Windows is a lot more secure than some folks will have you believe, but there is still one glaringly huge security flaw in Windows that would be ridiculously easy for Microsoft to fix: the accounts created during install time are all administrative accounts.
To its credit, Windows will allow you to change those accounts to non-administrative, and it will give you the option of creating non-administrative accounts when you later go in to the user cp, but by default, it still makes everybody an administrator unless explicitly told not to.
Now... the fundamentals of securing a Windows system are exactly the same as the fundamentals of securing a Linux system: don't run any unnecessary daemons, particularly daemons that listen to outside connections, and be careful what you allow to run on your computer. When possible, run anything that executes arbitrary code (like, say, Flash or Silverlight) sandboxed, or not at all. And above all, apply all security updates as soon as they're available. (well, assuming your source of security patches didn't get compromised....)
It's not hard to lock down a Windows system, and all of the above has been doable since NT3.1 in 1993. But as long as its default setting is for users to have administrative access, and it doesn't require any kind of secondary authentication to run programs with elevated permissions (and don't get me started on the debacle that is UAC), then Windows is *not* as secure as most Linux distros. The average user is simply not going to go out of their way to lock down a system once they have gone through the initial setup, and with that in mind, Windows is defective by design. It's in the name of usability, which is certainly understandable, but don't paint it with rose coloured glasses: you can achieve the same level of security under Windows, but you have to do more to reach it.
Re: (Score:3)
They aren't truly administrative (so long as you have UAC enabled) - they're more like normal user accounts that can sudo to root by providing their own password (rather than root's password) - not unlike Ubuntu. The default UAC setting skips the password, but that's because the whole point of inputting it is to prevent a malicious process from programmatically elevating on user's behalf - and UAC has a different way of handling that.
Huh? (Score:2, Funny)
But I've always been told by the fanboys that Linux is inherently secure, right? So that's not possible.
But Linux has no viruses/trojans/malware, right?
BTW - if you can't take this as the light jabbing it's supposed to be without wanting to rip my spine out, turn the computer off and take a break. :)
Re: (Score:2)
I suggest you look up the definitions of these words before you start using them.
Re: (Score:2)
But I've always been told by the fanboys that Linux is inherently secure, right? So that's not possible.
Hurr durr, patching the source code of software with malicious code means the software has always been inherently insecure....
Re: (Score:2)
Tell me... (Score:2)
Who's going to compromise the Linux kernel servers, and leave the linux kernel alone?
Re: (Score:2)
Considering they presumably include people from the major distros using the kernel.org compromise as a starting point to gain access into other organisations might be more valuable than a risky direct attempt on the kernel itself.
How it happened (Score:2, Troll)
The kernel.org sources live on OS X Lion boxes - authentication is handled through LDAP.
diff (Score:2)
s/police/hackers/ And i quote:
JeffK: "Oh noes, teh police! HIDE TEH LUNIX!!!11"
Highly unlikely the code was compromised (Score:3)
Here's a hint: the developers use git, which identifies all commits by their SHA1 value, so changing the contents of a commit will cause the SHA1 sum to mismatch which would cause git to howl and complain. So they then build a tarball and upload it to the server. They also upload signatures:
patch-3.0.4.bz2 29-Aug-2011 20:57 94K
patch-3.0.4.bz2.sign 29-Aug-2011 20:57 249
patch-3.0.4.gz 29-Aug-2011 20:57 107K
patch-3.0.4.gz.sign 29-Aug-2011 20:57 249
patch-3.0.4.sign 29-Aug-2011 20:57 249
So unless they manage to compromise the Kernel signing key any changes would be immediately noticeable (assuming people check the signatures, which they do).
Re: (Score:3, Interesting)
Re:How did they hack it? (Score:4, Informative)
The post on kernel.org states that it was possibly due to a compromised user account. They stated that they discovered it through some errors related to Xnest /dev/mem and that they captured some of the exploit code. I believe they're still looking at everything to figure how how the intruders got in and what they touched.
Kudos to the kernel.org team for their prompt action and immediate disclosure.
Re:How did they hack it? (Score:4, Insightful)
The post on kernel.org states that it was possibly due to a compromised user account. They stated that they discovered it through some errors related to Xnest /dev/mem and that they captured some of the exploit code. I believe they're still looking at everything to figure how how the intruders got in and what they touched.
Kudos to the kernel.org team for their prompt action and immediate disclosure.
How did the so called user account compromise result in root access? Care to explain?
Re:How did they hack it? (Score:5, Informative)
H.P.A. has commit privs and his work laptop was trojanned. That's how. Am I the only one who reads and understands the original e-mails from the admin?
Re: (Score:3)
Maybe he ought to use a laptop with OpenBSD, you think?
Re:How did they hack it? (Score:4, Informative)
Am I the only one who reads and understands the original e-mails from the admin?
Are you? "Intruders gained root access on the server Hera. We believe they may have gained this access via a compromised user credential; how they managed to exploit that to root access is currently unknown and is being investigated. "
Re: (Score:3)
I love linux, for a desktop and for back end servers. but for all else I use another OS
Re: (Score:2)
Xnest is an experimental nested server for X
why is anything related to X running on a server used for source control and such things?
especially because the X server executable is usually setuid root. seems to me that is asking for trouble.
and - why would anybody run experimental software on such an important server.
Re: (Score:2)
Xnest was a bystander. It was probably a binary where the backdoor/exploit was living after the original intrusion.
Re: (Score:2, Informative)
You have time to lookup the slackware documentation, but not read TFA?
"Trojan initially discovered due to the Xnest /dev/mem error message w/o Xnest installed."
Re: (Score:2)
Can you please explain how one can get an Xnest error message without Xnest being installed.
that does not make sense to me.
Re: (Score:3)
http://slackware.osuosl.org/slackware-13.37/slackware/x/xorg-server-xnest-1.9.5-i486-1.txt [osuosl.org]
Xnest is an experimental nested server for X
why is anything related to X running on a server used for source control and such things?
especially because the X server executable is usually setuid root. seems to me that is asking for trouble.
and - why would anybody run experimental software on such an important server.
I guess you didn't bother to read the article.
"Trojan initially discovered due to the Xnest /dev/mem error message w/o Xnest installed; have been seen on other systems. It is unclear if systems that exhibit this message are susceptible, compromised or not. If developers see this, and you don't have Xnest installed, please investigate."
Re: (Score:2)
% cat
Hello World.
^D
Re:Whoops! (Score:4, Informative)
Not really. Try reading the summary all the way through.
Re: (Score:2)
Yea? What part of that don't you understand?
Re: (Score:3)
Better question is... what part don't you understand? They think that the source is unaffected, but have not verified that yet. There is a chance, however small, that the source has been affected by this compromise, which is scary news for anybody who's built/updated a new kernel from source since the breech happened.
Re: (Score:2)
Also, when I go to kernel.org I generally see a lot of .tar.bz2 files for download. What's to stop an attacker from packaging a patched source and putting it in the place where most of the rolling release distributions are actually pulling it from? So what if the source tree is clean, if the packaged version is not then there was a problem.
Re: (Score:3)
What's to stop an attacker from packaging a patched source and putting it in the place where most of the rolling release distributions are actually pulling it from?
git, and the SHA-1 keys.
Re: (Score:2)
Yeah, those do nothing for the archive files sitting on the kernel.org homepage.
Re: (Score:3)
It depends. To check the signature , you need the signature, and a public key to verify it.
All an attacker has to do is use his own private key to sign the file , and then replace the public key with his own.
Then it would be verifying just fine.
Offcourse, if you have the public key ( rather than getting it from the site ) , you will know something is wrong.
Re: (Score:3)
But, most neanderthals can't even spell git, or SHA-1. There's no need to relieve their worries - just let them fret. That's the most exercise - mental or otherwise - that many of them will ever get.
This intrusion could be a good thing, all things considered. Maybe it will scare the morons away from using Unix-like kernels, and send them mewling back into the arms of Microsoft. It would be nice to see the "Year of the Linux Desktop", but face it. For that to happen, we'll have to welcome millions of id
Re: (Score:2)
Aren't the SHA-1 hashes themselves hosted on kernel.org?
forgot proper thing for sloccount data publishing (Score:3)
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
Re: (Score:3)
Here's a can of food for you to eat.
I am in the process of verifying if it has been tampered with, but I'm not 100% certain. It's probably ok.
Why aren't you eating it?
Re: (Score:2)
May I point out that you can't be 100% certain that ANY food is "safe" to eat? Unless, of course, you actually grow and process all of your own food.
Re: (Score:2)
Indeed, but in that analogy, the person who canned the food originally is where you would ordinarily place your trust and risk assessment (and whether that person/company has a good track record/has official recognition etc), and is they are saying "someone broke in to our factory last night and we're reasonably certain that the food is not poisoned, but we are still checking".
That's the point being addressed here - with the GP seeming to question reading comprehension (he believes the kernel source is tota
Re: (Score:2)
I would. Because that's exactly what the FDA et al does. Newsflash: people arn't perfect, and "pretty damn sure" might as well be "sure"
Re: (Score:2)
You're trying to dig your way out of a hole because you jumped the gun trying to "pwn" someone in the comments and have gone back and read the summary more carefully and now realise it does not say what you first thought.
Even with the FDA, if a situation occurs in a food factory (say, some guys break in and next morning you find empty bottles of poison on the floor), the owners are going to say "it doesn't look like any of the packaged containers have been tampered with, but we are in the process of checkin
Re: (Score:2)
This is what signed packages are for.
Re: (Score:2)
If the package signing key gets out in the wild, that is a problem. Aside from that, you cannot really have an issue where someone creates a fake package and gets it past a check, because they simply cannot generate the correct signature. SSL has a flaw that a browser will see "*.google.com" and trust it, even if it was not issued by the actual CA that Google uses. That issue does not exist with signed packages.
Re: (Score:2)
If the package signing key gets out in the wild, that is a problem. Aside from that, you cannot really have an issue where someone creates a fake package and gets it past a check, because they simply cannot generate the correct signature. SSL has a flaw that a browser will see "*.google.com" and trust it, even if it was not issued by the actual CA that Google uses. That issue does not exist with signed packages.
Who knows, maybe the intruder has the private signing key and the intrusion was simply to place altered packages? It's also not impossible, although extremely mathematically unfeasible to generate a package that has the same SHA-1.
Certainly, you can see how China would love to insert backdoor into the kernel.
Re: (Score:3)
> [ 71.610908] ModPointEnabledAccount[4485]: segfault at 7f51210dfaa8 ip 000000000040c544 sp 00007fffdadb5970 error 6 in .logicParser[400000+15000]
Re: (Score:2)
Re: (Score:2)
The bad guys have definitely won when it comes to credit cards, those rely entirely on security by obscurity. Other stuff, not so much.
And if credit card losses were the bank's/data-spilling organization's responsibility things would be VERY different...
Re: (Score:2)
None of the major distros use vanilla kernel.org kernels, so most Linux users won't be affected either way. Their update programs get kernel updates from their distro's servers, not from kernel.org. The distros are usually a few versions behind, so most won't be affected by this at all.
You can bet there's people at Debian, Ubuntu, Red Hat, etc. who are taking this very seriously. They aren't going to take any chances.
The only users out there who are potentially in danger are the ones that use kernel.org