Package Managers As Achilles Heel 263
An anonymous reader writes "Researchers from the University of Arizona have released a study that takes a look at the security of ten popular package managers. They were able to show all ten were vulnerable to attacks from a mirror or man-in-the-middle that allow an attacker to (along with other things) crash the system or obtain root access. Furthermore, the researchers created a fictitious administrator and company name and were able to lease a server and get it listed as an official mirror for all the distributions they tried (Ubuntu, Debian, Fedora, CentOS, and OpenSUSE). This raised the question: What keeps you up at night, the thought of attacks on your package manager or previously discussed and patched vulnerability in DNS?" justin samuel (one of the Arizona researchers) also points out a synopsis on CERT's blog.
Answer (Score:5, Funny)
What keeps you up at night, the thought of attacks on your package?
Yes.
Re:Answer (Score:5, Funny)
Re:Answer (Score:5, Funny)
Kittens? Ha! (Score:3, Funny)
Let me know when you have a 14lb. cat with bigass claws who likes to sit in your lap and use you as a scratching post.
Re:Answer (Score:4, Funny)
Iran's missile keeps me up at night more than my Ubuntu's package manager.
That depends on whether you live next door to one launchpad or the the other [launchpad.net].
I better update now (Score:5, Funny)
verify against other sites (Score:5, Interesting)
I think a lot of these risks could be reduced if people downloaded from one site and verified against one or more other sites. Furthermore, if the checksums were verified over SSL, some attacks would be harder.
Right now, verifying packages against a site other than the one they were downloaded from seems cumbersome with apt--or does anybody know of a simple command line to do so?
Package are already *signed* (Score:5, Insightful)
No need for anything as complicated as verifying packages accross several source :
most modern package managers use key-signing on package.
You can't setup a bogus repository and start serving malware to unaware users - those packages will fail the key check.
For that to work, the crackers would also have to find a way to inject their own keys into the ISO of the distribution, and they'll have to find a way doing it that still pass the checksum of the peer-2-peer client with which the users downloaded the ISO.
That might be possible with older p2p protocols relying on older weak hash, like eDonkey2k whose MD4 has known collisions, or even older protocols lacking checksums. (Some companies working for the media corporation back then used such possibility to pose as peer on the network and poisoning it by injecting bogus packets).
But distribution currently rely on bittorrent which use SHA-1 hash and it's (currently) much harder to find a way to inject tampered data and have the resulting file still pass the checks.
Another solution would be to trick the users into accepting a new set of keys to get onto the fake repository. For this, this repository will have to pose not as a mirror (as proposed in the TFA) but as an additional 3rd party repository hold functionalities not available in the original source (this is something that would benefit from the harsh imaginary-properties laws as most distro can't provide packages processing some media, and users have to rely on 3rd party repositories for this).
Besides, the summary is misleading. They didn't actually setup a bogus mirror that served maliciously crafted files, or otherwise injected malware (that would be impossible given the signatures).
They simply setup a mirror, that wasn't up to date on purpose, potentially exposing computer to exploit due to only older versions of software being updated.
As actual legit mirror may lag behind the release, it is nevertheless preferable to always add the original repositories to the list of source : thus get the files from the mirror if available there, or straight from the original website if not replicated everywhere.
This work around is even useful when there's no malicious intent.
Re:Package are already *signed* (Score:5, Interesting)
The packages are still signed with an a valid key. They are just older packages rather than the latest ones.
I have to give more thought to think if this will work, but I doubt that this has not occured to anyone else. I certainly thought of it before. Most likely the package managers have a way to keep this from happening already.
Their entire Proof of Concept seems to be:
I wouldn't panick until I see a CERT advisory, or as someone else pointed out, at least one real world incedent.
Re:Well, sign the catalog then. (Score:5, Interesting)
I just verified with my distribution, and the package metadata is not used when calculating the signature, so this is a valid vulnerability.
Re:Well, sign the catalog then. (Score:5, Informative)
Re: (Score:3, Insightful)
Well, to start with, Bittorrent is P2P, and some ISPs block it. In an ideal world you might have a point, but I'm not going to think about it too much. Alas, we live in a world where network neutrality is not a given, and they may start arresting people for using BitTorrent any day now :-(
... I hope I am being alarmist with that last part, but it wouldn't surprise me if the next step after Telecom Im
Re:Package are already *signed* (Score:4, Interesting)
Just to be very clear about this one point because it is sensitive: the public mirrors we setup and had listed as official repositories were kept up-to-date and we only served current metadata and packages. We served nothing that was out-of-date (beyond normal mirror update lagtime between rsyncs with the upstream mirrors) and we served nothing that had been modified.
All tests we performed related to what a malicious mirror could do (e.g. serving out-of-date metadata, serving modified metadata in the case of package managers that don't sign metadata, etc.) were performed using separate mirrors and clients of our own. Nothing we did with our mirrors put users at risk.
Re:verify against other sites (Score:5, Insightful)
This doesn't really make it more secure.
That's the kind of simplistic black-and-white view of security that is responsible for so many security problems.
Of course it makes it more secure if I verify against multiple sites and over SSL: it protects against many of the attacks described in that paper, so it will be harder for an attacker to mount a successful attack.
Re: (Score:3, Insightful)
Anything is better then nothing, even if you don't use SSL its still better. Rather the settup a fake package server ( easy ) and dupe you into using it ( probably easy ), the attacker now must compromise your DNS ( harder ) or dupe you into useing two of his fake package servers ( harder ).
Depends on bugs in old software (Score:5, Informative)
Just in case anyone thought (like me) that the vulnerabilities they're talking about might let an attacker install arbitrary software just through the package manager, this doesn't seem to be the case.
The attack might go like so:
The simple fix is to change the client so that it never regresses (e.g., never installs software older than what it already has installed).
Re:Depends on bugs in old software (Score:5, Informative)
The simple fix is to change the client so that it never regresses (e.g., never installs software older than what it already has installed).
That's a start, but then they can just keep you at the current version and when a new buffer overflow is found and an exploit created, then they hack you. Better validation of mirrors and package managers that check multiple repositories and compare the results are probably a more complete fix.
Re: (Score:2)
Or, require the "list of most recent packages" to be signed, sign it with a timestamp, and have the package manager reject old package lists.
There are plenty of other, more complicated schemes where packages known to have vulnerabilities could have their signatures invalidated.
Re:Depends on bugs in old software (Score:4, Insightful)
That's good and all until you download a bleeding edge version that is buggy as hell and want to go back to the old version.
Re: (Score:2)
Existing package managers won't regress unless you explicitly instruct them to. A standard apt-get update won't install older versions of packages just because they're in the list.
As I understand the 'vulnerability', all they can do is keep you on an existing version known to be buggy, but if that's the case then surely they would already know you don't have the latest version because they've been getting their updates from you, so you don't supply it in the first place, then you hack them.
Maybe I'm missing
Re: (Score:2)
switching subject and object half way through a sentence... go me :p
No regressions (Score:2)
Two minor points to object :
- Current package managers don't downgrade automatically. (Yast will show the version numbers in red, but keep the highest version anyway).
-People have at least 2 source for packages : :
1. a mirror of the distribution (containing all the packages)
2. a "security" update website, which generally is also able to use delta-packages.
some even add
3. the original repository, in case the mirror is lagging and doesn't have the latest version
Under those circumstances, the packages manager
"project" managers (Score:3, Funny)
The headline should be project managers as achilles heal.
Sounds real and exploitable.. (Score:5, Informative)
Until I RTFA, I was ready to dismiss this as 'failing to understand signed packages. Wrong, they understand package signatures all too well.
The basic attacks seems to be.
1. Obtain old, signed packages.
2. Become a mirror for debian|fedora|ubuntu|$distro.
3. Wait for vulnerabilities to be found in some package.
4. Do not serve the updated packages, continue to serve the vulnerable version.
5. Log IPs of machines downloading from your mirror.
6. Root them.
This works because some package manager software will download and use package metadata even if it's older than what's cached.
One long term solution would be to sign package metadata and serve it only from one central location, over https/sftp. There may be others.
Alex
Re:Sounds real and exploitable.. (Score:5, Insightful)
> One long term solution would be to sign package metadata and serve
> it only from one central location, over https/sftp.
Even that won't help. The authors got so caught up in the complex exploiting they didn't notice the BIG implication of their work. The problem can't be fixed with tech, crypto or anything but https connects to known to be trusted mirror operators.
Follow along as I demonstrate. Spamgang wants zombies so they install a massive mirror farm for all of the major distros. They run it perfectly, fully updated with upstream as fast as their phat pipe can get it, perfectly signed metadata, packages and everything offered by http or https. Then they wait.
Sooner or later another remote root bug, in openssh for example, will hit and they are ready. Thousands of machines either automatically connect or their owners see the story here on /. and hit the update button. They download that signed, correct metadata and sure enough their machines realize they need that new openssh package and ask the mirror for it. And are 0wned a few milliseconds later.
Because in the act of requesting the package all those machines just told the spamgang that a specific IP is a) running openssh, b) it is the vulnerable version and c) that host is currently connected to the network and very likely has the vulnerable software running. So in the time it takes the updated package to transfer, unpack and install they have ample time to get in and install a rootkit. The beauty is that the victim will patch the hole and thus prevent anyone else from getting the zombie.
Wait a random time before beginning to use the new zombies to help prevent people from getting wise to what is happening and the spamgang could likely get away with it for years.
Re: (Score:2)
Thanks for explaining what I was trying to explain in another comment much better than I managed to.
Re: (Score:3, Informative)
It also logs all requests for updates, and roots any box that requests an update from a known-to-be-vulnerable package. While it acts as a respectable mirror, it is also getting detailed information on what out-of-date packages you have, and has the ability to exploit them *before* the fix you requested is downloaded/installed.
The mirror is never out of date, it keeps it's signatures up to d
Re: (Score:3, Informative)
That will only work until the vulnerability is in something that can't be shut down during the update process, like the package manger or the kernel. That list might be small enough that it's practical to have a single, secure server for those updates, but it's an added complication to the problem.
Re:Sounds real and exploitable.. (Score:5, Informative)
As an aside... (Score:3, Informative)
As an aside, here's the famous "don't use kill -9" letter:
No no no. Don't use kill -9.
It doesn't give the process a chance to cleanly:
1) shut down socket connections
2) clean up temp files
3) inform its children that it is going away
4) reset its terminal characteristics
and so on and so on and so on.
Generally, send 15, and wait a second or two, and if that doesn't
work, send 2, and if that doesn't work, send 1. If that doesn't,
REMOVE THE BINARY because the program is badly behaved!
Don't use kill -9. Don't br
Re: (Score:2)
If the package manager simply refused to use metadata signed more than say, 3 months ago, wouldn't this help?
Not a real issue with Debian today (Score:3, Informative)
they basically say so themselves
Use signed repository metadata. If your package manager or distribution does not yet support signed metadata but only signed packages, at least require signed packages until signed metadata is supported.
Debian does that. The Release file defines what Package database files are available, and their md5sum's. It is signed.
the Package files include md5sum for the packages (can't modify the Package file otherwise signed md5sum in Release file will fail, can't modify the actual package as wont match md5sum in package file).
I would argue, that manually using the package manager (dpkg over apt) is less secure if one has apt set up correctly.
Re: (Score:2, Informative)
More than that, Debian has a very limited set of security mirrors, and the default configuration points to a round-robin set of mirrors (so even if one of n was compromised and stopped serving updates, and nobody noticed--very unlikely--you'd only hit that mirror roughly one out of n updates).
This article has all the hallmarks of a sensationalized report from someone either trying to impress people or generate page views. Sure it's relatively easy to add a relatively untrusted tertiary debian mirror, but th
Re: (Score:3, Interesting)
If you use the Debian Security Analyzer [www.enyo.de], you cannot simply supply vulnerable versions of packages as they will still be listed by debsecan.
MD5 (Score:2, Redundant)
1. Set yourself up as a mirror
2. Put old packages up with known vulnerabilities.
3. Distribute "updates" listing the old packages as new updates.
4. Watch your logs to see who updated with old packages, then go PWN them.
It also counts on lazy admins, but garsh how rare are those.
I guess
Re: (Score:2)
Then surely the key is not to get the current package list and md5 check from the same mirror that you download from.
If source 1 says package x should be this version and with this md5 sum then a mirror offering a different version and different md5 sum shouldn't be trusted automatically.
I don't think it would be too difficult to make the packaging system more robust than it is at present.
Not too worried (Score:2)
Yes, the vulerabilities are there. Not surprising to anybody that ever did a Debian mirror, for example. DNS spoofing already is enogh, not even a man-in-the-middle needed. Still, these are high-effort attacks. And with the IP addresses of the update servers used (instead of their names), MiM becomes neecessary. From my observations, MiM attacks oten need to be done in close physical proximity of the attacked machine. If somebody manages to get there, they can direcly manipulate my servers, with me possibly
Windows Update not vulnerable? (Score:3, Insightful)
TFA doesn't address Windows much. In the FAQ they say something like "since the vendor controls the repos for Windows and OSX, they are less vulnerable".
True, I can't set up a bogus mirror for Windows -- except in a corporate environment, where I believe MS has some facility to allow a local cache of patches to reduce external bandwidth usage.
But the authors keep talking about man-in-the-middle attacks on FOSS repos. Couldn't someone just as easily do that for Windows? And then use it to only offer outdated (known-vulnerable) versions of patches?
Slackware (Score:5, Funny)
As a maintainer of a repository.. (Score:2)
The metadata is signed as well as all the packages. This mitigates the situation, i.e. a malicious mirror cannot host arbitrary combination of packages to suit their needs, they must mirror some permutation that I had at one point approved all together.
Re: (Score:3, Informative)
But the malicious mirror also has a steady stream of data coming in, which includes IP addresses of people running vulnerable services, and which services those are. Before the patch is finished installing, the user is rooted.
n00by question (Score:2)
Forgive me for my lack of *nix prowess, but I've noticed that Package managers seem to be a predominantly Linux thing and unfortunately, I've not had the chance to get properly acquainted with the OS yet (I know, wtf am I doing here?). I've never encountered one in Windows, unless you count the handy package manager in DevC++.
Are there any good windows alternatives, or is it simply not needed thanks to windows having many a dedicated installation packaging program?
I wouldn't mind having one so I could get t
Re: (Score:2)
Oh and in case anyone complains, I already had a google around and could only find one project that hadn't been updated in about 2 years.
Re: (Score:3, Informative)
There really isn't an equivalent in Windows. I would imagine that it's because Linux is very modular, and almost all the software is free. Windows developers charge money and want you using their installer which (in some cases) requires license keys, etc...
It would be cool though if someone build a front-end for the Windows Installer (msiexec) that would let you
Re: (Score:2)
I'd love to, but unfortunately I don't really have the time to properly sit down and get used to a new OS.
I have far too many things to be doing and can only really migrate piece by piece.
At least if I can get used to working with Open Source equivalents to all of the applications I need to do whatever work I have, then eventually changing the OS isn't going to affect that too much. That's the theory, anyway.
I've tried just "switching" like that many times before and all it's done is just frustrate me as Li
debtorrent sounds neat (Score:3, Interesting)
from the cert overview:
Another potential solution to this problem is P2P technology. If widely used, programs like DebTorrent may allow official repositories to distribute metadata and tracker information while decreasing bandwidth costs.
I wonder why Ubuntu doesn't make this a standard option. Is port forwarding too complicated? From what I understand, if the package is not available via bittorrent, DebTorrent degrades to using http.
It's a true risk. (Score:3, Insightful)
This could be an issue... (Score:2)
Except that it is solved by MD5 checksums as noted by several people. A sophisticated attack of this nature would require being added as a mirror, accepted by your target as being genuine, and then taking on the provider of the checksum to provide a false one.
Of course, someone might take the time to develop a package with the same checksum as the actual file I suppose, but it has been so long since I've read up on encryption that I don't know how feasable this is. Anyone else? I'm fairly certain that by th
Gentoo & package-signing (Score:3, Informative)
For anybody interested on this in Gentoo, I have updated my GLEPs about signing the portage tree to include a Gentoo-specific solution for this, by distributing a copy of the top-level signatures by a trusted system:
http://robbat2.livejournal.com/226512.html [livejournal.com]
AFAICT - Debian is not vulnerable by default (Score:5, Insightful)
As far as I can tell, Debian is not vulnerable in its default install mode.
a - Debian will never automatically downgrade a package.
b - Security problems (as opposed to mere changes) get published in the Debian security repository.
c - The Debian installer automatically adds the debian security mirror to the end of your sources file.
So, you can create a mirror, easily inject it into the list of official Debian mirrors, and freeze the packages offered on it. You can do all that easily. It won't help you. If you take the CERT example, of the vulnerable openssl package, the fix was pushed through the security repository, and that is added by default to all new Debian installations. The attack would fail.
Furthermore, even if your mirror offered a security mirror as well, I, personally, always keep the Debian source as well, lower in the list. This way, if the local security mirror is up to date, I take stuff from there. If it's not, I take it from the Debian server. This means that even if you deviate from the default behavior, you can still be not vulnerable.
Shachar
Slackware (Score:3, Insightful)
There seem to be a lot of distributions whose package managers rely on the keys/hashes to "secure" the packages, where the mirrors are providing those keys/hashes. Silly idea - always has been, what makes this news?
What this article is basically saying is "anyone can be a mirror" (Yes, that's the point, without that you wouldn't be able to get a release/security update for ages after its release, or you could just take one website offline and stop all package updates worldwide - both are worse for security than the alternative) and "some package managers don't properly check the authenticity of a package from a mirror". The second is a problem that's easily fixed and shouldn't be present, granted. What idiot would accept a valid signed package without first checking that the root key it's signed with isn't current, valid and not revoked? This is like your web browser navigating to random SSL websites without first checking that the certificate chain is correct and valid and ends in a trusted root.
1) Download key from "redhat.com" or wherever (DO NOT USE MIRRORS), or from the CD, on first install.
2) Everytime you are asked to fetch a list of available packages, check the authenticity of that key against "redhat.com" directly (DO NOT USE MIRRORS), check the expiry date, check for revocation information, or allow the user to override (their fault), or check public keychains.
3) If the key ever changes, ALERT THE USER before you do anything with it (don't try and get smart by signing a package with the old key that introduces the new key to the world, or automatically accepting a new key). Then the distribution should NEVER use that old key ever again, and maybe even resign all old packages with the new key.
4) Use that key to verify all packages downloaded from any mirror against the GPG signature from that package (for ultra-security, get that from a second, random mirror, or the official website).
There's a small window of opportunity for compromise on machines that install packages without checking first, or assume that because a key was once valid it always will be, or are significantly out of date and don't check the "definitive" source for a new key first but you'll never remove that completely. The way to do that is to check the root key, reliably, on a regular basis. But then if you have an old machine that still has the key from the install CD, and that key is compromised, and the machine does not have reliable (read SSL with significant trusted chain) means of contacting the main server without possibility of spoofing for a new key, then you have a problem.
I don't see why this is "news" or even vaguely important except to show up distros that aren't ALREADY doing it this way.
BTW: This is why I do package management on Slackware using a script that makes *me* get the GPG-KEY from slackware.com first if it ever changes (including checking if the IP of ftp.slackware.com has changed, the date of the file has changed, the key itself has changed etc. but if they can compromise my access to Slackware.com without hitting one of those checks, I'm stuffed anyway), why I have an RSS feed of Slackware and check the website myself regularly (just in case the key requires changing and news is posted about it), why I only use trusted mirrors, why I download the GPG signature and package from seperate mirrors and why nothing gets installed without that GPG check succeeding. To be honest, I see this just as being sensible for anything that goes into production. I'm still waiting for a rogue Windows Update, but it surprises me that some distros (or administrators) don't ALREADY do all this...
Re: (Score:2)
RTFA
Re: (Score:3, Informative)
The article actually discusses attacks that can be made by a malicious mirror even if you are only accepting signed packages.
The actual vulnerability (Score:5, Interesting)
> The article actually discusses attacks that can be made by a malicious mirror...
Yes a mirror can keep you from getting a security update. But if you don't contact that mirror every day you will eventually get a good mirror and update, and since none of the package managers will downgrade automatically this is a mostly theoretical exploit.
Yes if a really BIG bug hits somebody could keep some subset of machines from updating, and since they would also KNOW the ip of each vulnerable host it could be very bad. That is the part that worries me, hell, they could even deliver the update from their perfectly up to date repo of signed packages, signed metadata AND perfectly in sync with the distro prime mirror.... and root your ass while the update is in flight. This gets to the real security vuln involved, telling an untrusted entity exactly which version (sorta) of a package you are running.
Re: (Score:2, Insightful)
Yes a mirror can keep you from getting a security update. But if you don't contact that mirror every day you will eventually get a good mirror and update, and since none of the package managers will downgrade automatically this is a mostly theoretical exploit.
Also, the article says "the malicious mirror can provide the client a signed list of packages from the year before", but I don't see how that can cause a problem, either, if I have updated a package within that year.
If I have foo-3.1.0 installed and the malicious mirror offers me foo-2.8.0, then I won't download it, because it doesn't provide newer versions of anything.
The big key in all of this is signed packages (no pun intended), since that keeps the bad guys from modifying the package to claim to be foo
Re: (Score:3, Insightful)
No. Your missing how it is done. The cracker mirror takes foo-2.8.0 and renames it foo-3.1.1
Since the file metadata (e.g. filename) isn't used in the signature calculation it still verifies as a valid signed package, and the system installs foo-2.8.0 because it believes it is foo-3.1.1.
Re:The actual vulnerability (Score:4, Informative)
There is considerably more metadata than the filename in all package systems.
Although I generally only use RPM, I have seen enough of others to know that each package has information inside it that says things like "supplies foo-2.8.0.so". For example:
$ rpm -q --provides openssh
config(openssh) = 4.3p2-24.el5
openssh = 4.3p2-24.el5
This sort of metadata is part of the headers that are downloaded by the package manager to determine whether the system needs the package, and what other packages might be needed to fulfill dependencies. So, the system probably won't even download the file just because it was renamed. But, even if it does download it, when it tries to install it, you would get an error because a newer version of the capability (RPM term) named "openssh" is already installed.
You could always force the install, but no package manager does this sort of downgrade as an out of the box default
Re: (Score:3, Informative)
Re: (Score:3, Informative)
Re:Vendors sign with keys. (Score:4, Informative)
Considering Fedora (at least) signs all packages, seems like the authors should have been clear if the attack still works if the packages are not signed.
The article seemed pretty clear to me. The most vulnerable systems don't have signed packages or metadata or expiring signatures. The least vulnerable systems have all of those, but are still potentially vulnerable for a window of time before the metadata signature expires but after a vulnerability is found and fixed in a package.
Re: (Score:2, Informative)
Thanks for reading the article.
The point is that there are plenty of signed (but old and vulnerable) packages that can be given to your system that it will gladly accept leaving you open to attack.
Re: (Score:2)
That's true, but are you sure that you're getting the keys in a secure way in the first place? Since people generally download the ISO without encryption, the ISO may have been altered as well. And are you sure the commands you display things with haven't been altered either? To really be sure, you probably would need to get a physical CD from a trusted source, including all keys, and then verify your entire system from that.
Still, I think that the larger risk for trojans still comes from people planting
Re: (Score:2)
Re:Vendors sign with keys. (Score:4, Informative)
They're saying that signing the package isn't good enough.
I think the threat they're describing is based on this idea: your Linux Vendor signs package foo-1.0. People being fallible, a security vulnerability is eventually found in foo-1.0. It gets patched. foo-1.1 comes out, and your vendor signs that too, and you install it. You are happy.
Then, one day, you tell your system to update everything. Your computer talks to some mirror, and gets a list of the latest packages. Then you download the latest packages. Oh look, here's foo-1.0. Oh good, it's signed by the vendor, therefore it's safe. You install it.
Oops, the mirror just tricked you into installing software with a known bug. The package was signed, but the information about what is the best package to download and install, wasn't signed.
Re:Vendors sign with keys. (Score:5, Informative)
What package manager silently downgrades packages?
I can see a package mirror (maliciously) refusing to stock updates, but yum at least picks a mirror at random by default. Apt didn't last I saw, but if you picked your own mirror, you already trust them.
Re:Vendors sign with keys. (Score:4, Informative)
But both Ubuntu and Debian have central security mirrors for security updates, which are added by default.
For this it doesn't matter (much) if a regular package mirror doesn't have the latest openssh, the security mirror will have one with the security fix in.
Now, there could possibly be some cases where security fixes gets published as regular updates where a replay attack could be successful. If the story would load off the apparently slashdoted web server, I could see if they had seen such issues, etc.
Re:Vendors sign with keys. (Score:4, Informative)
Ok, so foo-1.1 is uploaded on security.debian.org.
What are the official mirrors for security.debian.org ?
None. And if you decide to use some mirror anyway, try at least to select one you trust.
End result : everyone gets the patched foo-1.1
That's why Debian signs repositories (Score:4, Insightful)
They're saying that signing the package isn't good enough
That's why Debian doesn't sign packages; they sign repositories. (Actually, they sign a list of md5sums of all avaiable packages.) You can actually argue that signing a package is counterproductive--it means that an insecure package out in the wild will still have a valid signature.
When you sign the repository, then an attacker has to freeze their whole repository if they want to keep the insecure package available. For Debian Unstable, people will get very suspicious if more than two days go by without any updates. And for Debian Stable, well, the security repository isn't mirrored, so owning an "official" mirror won't help you there. (The security repository could be vulnerable to a MITM attack, but then so could MS's system.)
So, while the attack vector they mention for Debian seems superficially plausible, in practice, it's unlikely to be as effective as they suggest.
Re: (Score:2)
RTFA. The key is valid forever. A server could have your machine load a previous version of software that has already been signed by the vendor. The previous version may not have a security fix and may be exploitable. Then your machine is compromised.
Re: (Score:3, Insightful)
A server can't make your machine do jack shit. Your machine is the one that pulls an old version and downgrades to it. If your package manager silently downgrades packages then that's a flaw in all cases. What if a mirror just happens to be out of date?
Re: (Score:2)
I could answer that, but the short article you didn't read already does.
Re:Compile from source yourself! (Score:5, Insightful)
How does compiling from source help? Trojans can be introduced in source code just as easily as in binaries.
Re: (Score:2, Funny)
It doesn't help at all. The grand parent is a twelve year old that discovered Gentoo yesterday. Gentoo is '1337' yo.
Re:Compile from source yourself! (Score:5, Funny)
You've got him all wrong. He's a twelve year old with a PhD that reads and understand every line of code before he allows it to execute on his own hardware.
Re:Compile from source yourself! (Score:5, Funny)
Re:Compile from source yourself! (Score:4, Insightful)
Re: (Score:2, Informative)
...exactly what happened to PHP a couple of years ago.
But the general theme this post rings is: in FOSS, if you don't (as hardly any end user does) inspect the source code, know and trust the origin.
It won't be long before those who write `malware' will start searching for ways to get hold of linux desktops. And for them, prospects aren't that promising with blunt exploits against whatever is running on your linux desktop with some ports open. Neither, I earnestly hope, will an average linux user be so ou
Re: (Score:3, Informative)
It's also plausible that a package manager could be compromised. It's unlikely with a major distributor like Canonical, Redhat, Novell, etc. but more likely if you use third party repositories.
Packages managers put one more link in the security chain. In most cases, it's probably not the weakest link,
Re: (Score:3, Insightful)
Re:Compile from source yourself! (Score:4, Insightful)
I really don't understand what the big advantage is in using package managers. It's dangerous because you never know what "updates" will come down the pike.
Normal people don't want to have to keep up on what the latest version of everything is as it comes out and what security holes are in it. That's one of the main reasons people use distributions instead of hacking together their own. People want knowledgeable experts to make the decisions and let the computer do the rest.
Re:Compile from source yourself! (Score:5, Insightful)
Unfortunately it's not nearly as easy to type: ... ... x20
wget http://blahblah/dep1.tar.gz [blahblah]
wget http://foobar/dep2.tar.gz [foobar] (404 Sigh)
wget http://woobar/dep2.tar.gz [woobar]
wget ftp://wowowow/dep2.1.tar.gz [wowowow]
Followed by:
tar -zxvf files.tgz x 20
THEN followed by: ./configure && make && make install x20 IN THE RIGHT ORDER
times
Plus however long it takes you to debug the eventual compile problems because one of those obscure libraries that only one program uses was installed earlier with the wrong version.
All said and done, I'd rather take my chances with package managers, thanks.
Re: (Score:3, Insightful)
Hear! Hear!
When it becomes a problem like it is for Windows, I will then take notice.
From my point of view, it's all 'nothing to see here, move along.'
I will admit that the increasing popularity of *nix will eventually will make this an issue, the time is not now. Give it a few years and marketshare increase on the desktop.
The source is always available to be checked, so I don't see a problem here unless someone like MS is trying to 'poison the well' to try to increase their marketshare. This is FUD as far
Re:Compile from source yourself! (Score:4, Informative)
Now you get your package management AND you get to compile from source. Best of both worlds.
Re:Compile from source yourself! (Score:5, Insightful)
If you are downloading from a mirror, someone could apply similar methods to insert malicious code in your version of the source. And checking all of the source code is no trivial matter, especially if you are looking for an intentionally obscure bit of code.
Also, you have to trust your compiler [bell-labs.com], which you *had* to get from someone else. Your compiler may be inserting malicious code.
Re: (Score:3)
so you grab the same code from 3+ different mirrors and check them against each other...
Re:Compile from source yourself! (Score:5, Funny)
Also, you have to trust your compiler, which you *had* to get from someone else.
Nah, I wrote my own compiler directly in machine code. I didn't trust my keyboard manufacturer either, so I tapped out Morse code on a homemade key. I made the BIOS out of coconuts, but that was just because that douchebag Gilligan said it couldn't be done.
-Roy Hinkley
Been there, done that (Score:3, Interesting)
You joke, but I've actually built gcc with a C interpreter, and used that to build gcc binaries. We did it primarily as a stress-test of the interpreter, but it was nice see that the resulting gcc binaries were the same as those built with a compiled gcc.
Re: (Score:2, Funny)
Re:So, Linux is not more secure? (Score:5, Insightful)
The short answer : yes
The longer answer : every OS is vulnerable one way or another. The difference lies mostly in the response and the response time by the vendors.
Linux : take the debian ssh disaster a few month ago as example. I read about it at Google News, head over here to check how the linux bashing was coming along, and while I was reading, the "update available" icon appeared. A few minutes later and the vulnerability was no more. .. people who actually CAN fix this kind of problems, not your average /. reader)
Admitedly, it took a *VERY* long time to find out about the problem in the first place, but the response time from then on was very short, and the update contained concise information about the whole mess.
Today's vulnerability will probably take a bit longer to be fixed, as it requires some primordial changes in the way packet manager work to be fixed. But I'm rather sure people are already looking for a solution (you know
Apple Mac : when Apple admits that there is a vulnerability in their products, they take their dear sweet time to fix it. As a matter of fact, Apple just released a security fix for Apple TV, covering vulnerabilities dating back to, at least, January 2008 (at which time it was fixed for OSX, but NOT for Apple TV). I can't comment on how detailed the security fixes are, as I don't own apple products
Microsoft : the Zero Day initiative still lists 12 issues concerning Apple product, classified as "high severity", but the oldest item is a Microsoft vulnerability dating from September 2006 (more or less quoted verbatim from the iWire article I'll link to a bit later). Microsoft updates are particularly obscure in their descriptions, and, if I remember correctly, they are sometimes even applied without asking the user first, and have a bad habbit of breaking other stuff.
So, is Linux 100% secure? No, and it will never be. But at least the devs react in a timely manner, and they don't just install something without telling you what it is or that they are patching at all. Therefore it is better secured than Apple and Microsoft products whose vulnerabilities are often left open, for the sake of obscurity I suppose.
"Superiority" is a highly subjective term, so I won't even start to thread on this subject. It is for me, but your mileage might vary
Apple TV fix article [itwire.com]
Zero Day Initiative upcoming advisories [zerodayinitiative.com]
Re:Hmmm (Score:4, Informative)
Comment removed (Score:5, Funny)
Re:Neither (Score:5, Funny)
Re: (Score:3, Funny)
Re:Neither (Score:5, Funny)
I'm almost certain you didn't.
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Re: (Score:3, Funny)
I don't think you did.
Re: (Score:2, Funny)
Neither keep me up at night, I have a girlfriend and things to get done.
Perhaps you should consider changing your girlfriend, mine can always keep me up.
(for those without sense of humour up is used as erected)
Re:Neither (Score:4, Funny)
Neither keep me up at night, I have a girlfriend and things to get done.
Perhaps you should consider changing your girlfriend, mine can always keep me up.
(for those without sense of humour up is used as erected)
Do you often find yourself having to explain your erections?
Re: (Score:2)
You always know the troll pushing XP.
I have a rather complex Mandriva operation myself, I've talked about it before. Anmd You are wrong. totally wrong. You can install autotools, automake, and all that other stuff.. Thats a dependancy of the rpm-build package. I have all Mandriva 2008.1 domains up and running, '
I am currently chasing an ALSA buffer under run in D2X-XL.
But anyway. Yes my machines otherwise work fine. This person is probably having other issues. Like, bad DNS redirection.
Notice how the first