×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Package Managers As Achilles Heel

timothy posted more than 5 years ago | from the dip-your-computer-in-the-styx dept.

Security 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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

263 comments

In Soviet russia (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24144891)

the government controls the first post

Re:In Soviet russia (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24144993)

In Soviet Russia, first post posts you!

first post (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24144897)

first post!

Hmmm (0)

Anonymous Coward | more than 5 years ago | (#24144919)

I don't keep anything open on my firewall so nothing really keeps me awake at night. I got hit by slapper like 8 years ago when I didn't even use a firewall, but since then - nothing.

Re:Hmmm (4, Informative)

Anonymous Coward | more than 5 years ago | (#24145237)

Your firewall won't stop this type of attack... RTFA.

Re:Hmmm (5, Funny)

woodrad (1091201) | more than 5 years ago | (#24145535)

Yeah, my firewall blocks all traffic too. It's just more satisfying than having no NIC, and nearly as secure.

Archillies Heel (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24144921)

The only reason Paris was able to hit such a small target was he used to be an Elf with extra archery prowess

I better update now (5, Funny)

Krneki (1192201) | more than 5 years ago | (#24144931)

... oh wait!

Re:I better update now (0)

Anonymous Coward | more than 5 years ago | (#24145621)

This reply is written from a debian primary mirror.
(this is not a joke, check the webserver logs)

Neither (-1, Flamebait)

MisterSchmoo (1262374) | more than 5 years ago | (#24144939)

Neither keep me up at night, I have a girlfriend and things to get done.

Re:Neither (4, Funny)

HappySmileMan (1088123) | more than 5 years ago | (#24145343)

I bet your girlfriend doesn't keep you up at night either... It's ok, someday you'll find someone who loves you

Re:Neither (2, Funny)

__NR_kill (1018116) | more than 5 years ago | (#24146061)

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 (4, Funny)

MisterSchmoo (1262374) | more than 5 years ago | (#24146133)

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?

Compile from source yourself! (0, Troll)

suck_burners_rice (1258684) | more than 5 years ago | (#24144949)

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. Thanks to the good folks who contribute to GNU Autotools, it's very easy to type ./configure followed by make and make install. Even end users can do this with a pretty high success rate. If there is a reason that you really need a package manager (for example, if you're a sysadmin responsible for many computers) then you can easily make your own packages and avoid trusting someone else's package decisions. Updates can be convenient, but they can screw things up really badly.

Re:Compile from source yourself! (4, Insightful)

speedtux (1307149) | more than 5 years ago | (#24145019)

How does compiling from source help? Trojans can be introduced in source code just as easily as in binaries.

Re:Compile from source yourself! (2, Funny)

Anonymous Coward | more than 5 years ago | (#24145161)

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! (5, Funny)

77Punker (673758) | more than 5 years ago | (#24145233)

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! (5, Funny)

Anonymous Coward | more than 5 years ago | (#24145791)

Noob, he doesn't need source. I'm a 13 year old PhD and I assure you even I can read binaries.

Re:Compile from source yourself! (3, Insightful)

HappySmileMan (1088123) | more than 5 years ago | (#24145257)

You don't type './configure', 'make' or 'make install' when installing stuff on Gentoo, it has a package manager, but thanks for playing

and they said (0)

Anonymous Coward | more than 5 years ago | (#24145475)

teen pregnancy was on the decline.

Re:Compile from source yourself! (2, Informative)

SMOKEING (1176111) | more than 5 years ago | (#24146187)

...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 outright... er... end-userish as to go happy-clicking on links in spam.

Instead, setting up or overtaking some ftp.xx.debian.org is only sensible and effective to this end.

Re:Compile from source yourself! (2, Insightful)

reset_button (903303) | more than 5 years ago | (#24145077)

I like to have the latest versions of programs, with the latest features and bug fixes, without having to check the website for the latest available version, download it, compile and install it. Multiply that by tens of programs, and it's no fun at all. Additionally, when installing programs, there's no hunting down dependencies.

Re:Compile from source yourself! (1, Insightful)

Anonymous Coward | more than 5 years ago | (#24145101)

It's also very easy to hunt down hundreds of dependencies, right?

Re:Compile from source yourself! (3, Insightful)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#24145111)

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! (5, Insightful)

TikiTDO (759782) | more than 5 years ago | (#24145177)

Unfortunately it's not nearly as easy to type:
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] ... ... x20

Followed by:
tar -zxvf files.tgz x 20

THEN followed by:
times ./configure && make && make install x20 IN THE RIGHT ORDER

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:Compile from source yourself! (2, Insightful)

rts008 (812749) | more than 5 years ago | (#24146175)

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 as I am concerned. (I maintain backups, so WTF?!- let's see a problem with this before we jump the gun(or shark))

Re:Compile from source yourself! (4, Insightful)

skeeto (1138903) | more than 5 years ago | (#24145185)

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:Compile from source yourself! (2)

hitmark (640295) | more than 5 years ago | (#24145881)

so you grab the same code from 3+ different mirrors and check them against each other...

verify against other sites (4, Interesting)

speedtux (1307149) | more than 5 years ago | (#24144953)

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?

Re:verify against other sites (0, Flamebait)

WarJolt (990309) | more than 5 years ago | (#24145163)

One could use a fake DNS to route all traffic to exploited servers. This doesn't really make it more secure.

Re:verify against other sites (4, Insightful)

speedtux (1307149) | more than 5 years ago | (#24145243)

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:verify against other sites (2, Insightful)

DarkOx (621550) | more than 5 years ago | (#24145569)

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 ).

Package are already *signed* (5, Insightful)

DrYak (748999) | more than 5 years ago | (#24146153)

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.

Vendors sign with keys. (0, Redundant)

Zombie Ryushu (803103) | more than 5 years ago | (#24144969)

Every Linux Vendor I can think of signs the package with a key. Just make sure that the package manager won't install the application without a key.

Re:Vendors sign with keys. (2, Informative)

blueg3 (192743) | more than 5 years ago | (#24145043)

The article actually discusses attacks that can be made by a malicious mirror even if you are only accepting signed packages.

The actual vulnerability (5, Interesting)

jmorris42 (1458) | more than 5 years ago | (#24145617)

> 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:Vendors sign with keys. (2, Informative)

pembo13 (770295) | more than 5 years ago | (#24145047)

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.

Re:Vendors sign with keys. (3, Informative)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#24145183)

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:Vendors sign with keys. (0)

Anonymous Coward | more than 5 years ago | (#24145057)

Every deb package I install is GPG-signed. How can a bad mirror harm me? Distribute malicious packages with a correct footprint?

Re:Vendors sign with keys. (1)

blueg3 (192743) | more than 5 years ago | (#24145323)

I could answer that, but the short article you didn't read already does.

Re:Vendors sign with keys. (2, Informative)

Anonymous Coward | more than 5 years ago | (#24145115)

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:Vendors sign with keys. (1)

speedtux (1307149) | more than 5 years ago | (#24145131)

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 them in sources or binaries; any small open source project and any packager could introduce a trojan, and it only takes one.

Re:Vendors sign with keys. (3, Informative)

Sloppy (14984) | more than 5 years ago | (#24145143)

Every Linux Vendor I can think of signs the package with a key. Just make sure that the package manager won't install the application without a key.

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. (5, Informative)

kwalker (1383) | more than 5 years ago | (#24145223)

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. (0)

Anonymous Coward | more than 5 years ago | (#24145895)

The replay attack is limited: it freezes your software, so it lasts until your next update with a new server. (Imagine it running from the exploit discovery until a week or so after the security update.) The article mentions a scenario where one is given a snapshot from a year ago, but then the attack would be much less useful because of the downgrade warnings (which could be avoided by having a user install a statically-linked exploitable older package or hoping not enough users will mind the warning to keep the server up for a few more days.).

The article mentions random repository choosing in light of absolute security: if you are randomly given an replay-attack server, then you are vulnerable for that period. In essence, it implores users to do a better job of verifying server trust than the distributions (which seems circular to me unless someone or a company has the resources to verify servers).

Re:Vendors sign with keys. (4, Informative)

alrj (918878) | more than 5 years ago | (#24146143)

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

Re:Vendors sign with keys. (1)

WarJolt (990309) | more than 5 years ago | (#24145201)

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:Vendors sign with keys. (2, Insightful)

Rakishi (759894) | more than 5 years ago | (#24145623)

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?

Depends on bugs in old software (5, Informative)

xZgf6xHx2uhoAj9D (1160707) | more than 5 years ago | (#24145003)

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:

  1. the attacker finds some really old version of some software that they know to be buggy. E.g., they find OpenSSH version negative 5 or something, which had a terrible buffer overflow bug in it. This software has already been signed (years ago) by the package authorities
  2. the attacker then sets up a mirror with only the broken version of OpenSSH on it
  3. when a hapless Linux user goes to update OpenSSH, your mirror replies saying "the newest version is negative 5. See! I even have a 5 year-old certificate for it"
  4. your client says "...oh...okay"
  5. you install the old, buggy version of OpenSSH
  6. the attacker has your IP address and knows that you downloaded (and presumably installed) the old version of OpenSSH
  7. the attacker haxx0rz you

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 (4, Informative)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#24145061)

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:Depends on bugs in old software (1)

blueg3 (192743) | more than 5 years ago | (#24145089)

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 (3, Insightful)

thatskinnyguy (1129515) | more than 5 years ago | (#24145363)

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 good and all until you download a bleeding edge version that is buggy as hell and want to go back to the old version.

The simple fix is to change the update applications so that it never regresses (e.g., never installs software older than what it already has installed).

Re:Depends on bugs in old software (1)

tolan-b (230077) | more than 5 years ago | (#24146073)

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 something in the article? It doesn't seem to make sense.

Re:Depends on bugs in old software (1)

tolan-b (230077) | more than 5 years ago | (#24146083)

switching subject and object half way through a sentence... go me :p

Sounds real and exploitable.. (5, Informative)

moreati (119629) | more than 5 years ago | (#24145041)

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

or just not update so much (0)

Anonymous Coward | more than 5 years ago | (#24145745)

Run only from a known good iso image burned to a read only disk that you got direct from the project pages ftp server and be done with it, and stop worrying about day to day minuscule and near useless point.xyz updates. Once or twice a year, get a new one. Make your surfing machine be just an appliance, fast cpu, ton of ram, turn it off and on when you need it. See, it isn't that hard. Leave all your other work stuff for a non internet connected machine or machines. Airgap the important stuff, run from disk for casual surfing. If you need to move some stuff over, sneakernet it, keep that airgap intact. If you are doing this professionally for your business and need to stay current and it has to be hard drive installed all across your LAN, just get it direct one time and serve it out to your users, skip all the mirrors. Heck, pay the dudes their dollars (they deserve it really and you can deduct it anyway as a biz expense) and get them to send you the disks direct, eliminate most MIM vectors that way (if joe badguys have compromised the *post office*, for some reason you are a major target, so little hacked software packages are the least of your worries right now).

Re:Sounds real and exploitable.. (5, Insightful)

jmorris42 (1458) | more than 5 years ago | (#24145841)

> 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:Sounds real and exploitable.. (1)

tolan-b (230077) | more than 5 years ago | (#24146139)

Thanks for explaining what I was trying to explain in another comment much better than I managed to.

Re:Sounds real and exploitable.. (1)

v1 (525388) | more than 5 years ago | (#24145859)

If the package manager simply refused to use metadata signed more than say, 3 months ago, wouldn't this help?

Re:Sounds real and exploitable.. (1)

Daengbo (523424) | more than 5 years ago | (#24146107)

Torrent/Jigdo the current package list AND the packages. The tracker would be on a trusted server.

So, Linux is not more secure? (1)

n1_111 (597775) | more than 5 years ago | (#24145113)

Every week there is a news like this, and I must believe that Linux is superior and better secured?

Re:So, Linux is not more secure? (2, Funny)

Anonymous Coward | more than 5 years ago | (#24145187)

Yes. Yes you must.

Re:So, Linux is not more secure? (5, Insightful)

sammyF70 (1154563) | more than 5 years ago | (#24145641)

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.
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 .. people who actually CAN fix this kind of problems, not your average /. reader)

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]

Not a real issue with Debian today (2, Informative)

spotter (5662) | more than 5 years ago | (#24145153)

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:Not a real issue with Debian today (0)

Anonymous Coward | more than 5 years ago | (#24145283)

Indeed.
A man-in-the-middle-attack with Debian would be pointless, what with their frequent updates.

Re:Not a real issue with Debian today (1, Informative)

virtual_mps (62997) | more than 5 years ago | (#24145855)

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 the article fails to explain how that's relevant to compromising security updates from the security mirrors (which are, by default, added as a separate entry in the sources.list file).

It's also possible to put a close, fast mirror at the top of the list and add another slower but more reliable one lower in the list. apt will automatically choose the newest package from the closest available mirror.

Did the article's authors really investigate the debian infrastructure before writing their faq entries?

MD5 (1, Redundant)

InlawBiker (1124825) | more than 5 years ago | (#24145203)

The summary is a little misleading because you can't just replace, say, 'ls' with 'exploit-binary-named-ls' because it'd fail the MD5 check. But a MITM constructed like they suppose could easily work. Briefly, it is:

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 it comes down to controlling distribution of the updates. Kudos to these Arizona guys. This is a really simple method that can cause complete mayhem in uncountable ways.

Re:MD5 (1)

blackest_k (761565) | more than 5 years ago | (#24145613)

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.

experience with Gentoo (0)

Anonymous Coward | more than 5 years ago | (#24145291)

It's quite a while back, that I used Gentoo, so I can't remember all details.

I wasn't able to update a system package, because updating the portage tree had killed the file responsible for the system to know about the system packages. I was told this was no bug but a feature and within days I had migrated all machines to another distribution.

In this context we discussed the vulnerability of all these package systems.

cb

Did anyone check Mandriva? (1)

f2x (1168695) | more than 5 years ago | (#24145295)

I've been using Mandr(ake/iva) for years now, and some of their releases were OK, while others crashed and burned. It was cool though, because it was usually fast and breezy to set up. When Mandriva One 2008.1 came to town, I was impressed! Hardware detection and support was faster and better than ever! It set up so smooth and dreamy, you would have to be crazy to use anything else. Then the updates started happening... Sometimes several every week. Then it got cranky. Web access isn't quite so responsive as it used to be. I had to give it up on my EEE and resort to using XP. My desktop is lumbering through it, but I'd still like to format and re-install with 2007.1. The major trouble with Mandriva One 2008.1 is they don't actually include your make/install, build tools so you have to use their package manager over the net. It's not such a dreamy feeling anymore.

All that, and I'm not so sure Google or Firefox are necessarily my friends anymore either... Did the good guys lose or something? What's happening here?

Re:Did anyone check Mandriva? (0)

Anonymous Coward | more than 5 years ago | (#24145481)

Don't use Mandriva One then. If you install from the DVD or use the CD Image from the DVDPath/i586/install/images/boot.iso and install over the 'net it will give you the option of installing all the build tools OR you can install the meta-packages such as task-c-devel, task-c++-devel and the like. The 2008 distro of Mandriva allows you to see only these meta-packages in the package manager. I've been using Mandriva for years, have tried Ubuntu and Fedora and others and always come back to Mandriva.

The more things change.... (1)

domatic (1128127) | more than 5 years ago | (#24145517)

....the more they stay the same. I was a Mandrake user 5 years ago. Compared to everything else around, it was the slickest out of the box. But the the Drak* tools were always flaky, as were the update tools, and I could never find a mirror that was worth a damn even if the package manager was working well that day. Hell, it made Windows ME look like a paragon of polish and stability.

Going to Debian after that was like a breath of fresh air. Sure it wasn't packed full of wizards and GUI config tools but once configured into a working configuration it STAYED working. I've been running either Debian or a Debian derivative since. I've thought that maybe by now Mandr(ake|iva) would have improved. It looks like they're still up to their old ways of surface polish atop a creaky collection of dirty hacks.

Re:Did anyone check Mandriva? (1)

Zombie Ryushu (803103) | more than 5 years ago | (#24145685)

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 time things get a little flaky he runs for XP as fast as he can?

Re:Did anyone check Mandriva? (0)

Anonymous Coward | more than 5 years ago | (#24145725)

Parent post is proof positive that just because you run Linux it doesn't mean you're a nerd.

university repos! (0)

friedman101 (618627) | more than 5 years ago | (#24145375)

this is by no means a cure all but you're generally going to be okay if you only use mirrors that end in .edu. i use arch linux which doesn't do any fancy digital signing stuff but until someone hacks the repo at georgia tech i won't start to panic.

use established repos, duh

Not too worried (1)

gweihir (88907) | more than 5 years ago | (#24145429)

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 not even noticeing. The effort for that is hogh enough that I do not care, since the stuff on the servers is not worth enough to justify the attack cost by a fair margin.

So, no, I have 2 v-servers and one remote and one local dedicated server, all with Debian and automated updates and I sleep fine.

The maintainers are the real threat (0)

Anonymous Coward | more than 5 years ago | (#24145499)

Who cares about the managers as a whole. As long as you have clueless people maintaining the packages in question it doesn't really matter what manager you use. Does anyone recall the Debian openssl debacle? I still wonder what happens with a cluebie like that..

And if I may vent some personal annoyance.. People kept whining about GoDaddy not too long ago (they ripped 'm off, some GoDaddy dude bid on domains which were already ignored and vacant and they abused some peoples hamster) but why aren't we reading how GoDaddy now acknowledges their role as a true SSL Certificate Authority and as such allows people who have been using "suspected" openssl versions to re-issue their certificates?

And to get back on topic; that gesture too is the result of a single package maintainer (not manager) screwing up. So; beware the maintainers, not the managers as a whole.

I definitely worry most about... (0)

Anonymous Coward | more than 5 years ago | (#24145553)

...attacks on my package.

Windows Update not vulnerable? (2, Insightful)

schwaang (667808) | more than 5 years ago | (#24145589)

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?

As a maintainer of a repository.. (1)

Junta (36770) | more than 5 years ago | (#24145603)

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.

results in short: what manager(s) are the best? (1)

wandm (969392) | more than 5 years ago | (#24145633)

FTA:

Q: I'm worried about security and have a choice of package managers. What package manager should I use?

A: It depends on your situation. If you are using a distribution like RedHat Enterprise Linux or SUSE Linux Enterprise that support HTTPS and do not have mirrors run by outside organizations, then you are most likely safe from the attacks described here.

If you use a distribution that does not have these features, we strongly recommend using a package manager that signs the repository metadata and supports HTTPS. Of the package managers we examined, APT-RPM, Stork, and YaST have this support by default and APT has an optional package to support HTTPS.

n00by question (1)

neokushan (932374) | more than 5 years ago | (#24145635)

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 the latest and greatest Open Source/Free software that I may or may not have heard of, would be a great help for when I want to switch over to Open Source only apps.
My thinking is if there's an easy way to find/install good OSS, then I can get used to that first and thus my eventual transition to an Open Source OS will be much easier as I will only have to figure out about 200 things to do differently instead of 300.

Re:n00by question (1)

neokushan (932374) | more than 5 years ago | (#24145655)

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:n00by question (1)

Sir_Lewk (967686) | more than 5 years ago | (#24145723)

I know it may sound harsh, but I sincerely suggest just making the jump and going with a dual boot install. Choose a distro that's GUI intensive and let Gnome or KDE cushion you while you get used to the rest of the system.

Re:n00by question (1)

neokushan (932374) | more than 5 years ago | (#24145783)

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 Linux is just so different from what I'm used to. Not knowing how to do even the simplest of tasks, such as mounting a Hard Drive (something I could do on windows with my eyes closed), just makes me feel stupid and completely puts me off.

debtorrent sounds neat (3, Interesting)

rubberglove (1066394) | more than 5 years ago | (#24145693)

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. (2, Insightful)

drolli (522659) | more than 5 years ago | (#24145703)

It is really risky not to have a revokation mechanism for packages, but definig this by availability of a new package somewhere. The only solution would be to have servers, which contain a list of revoked packages. If connecting to these list fails, the update should stop.

Simple Solution (0)

Anonymous Coward | more than 5 years ago | (#24145741)

Disclaimer: Mirrors/Package Download Managers are the risk, not the Package Manager.

APT is not a package Manager, it is a Package Manager Manager. RPM/Debs are the package Managers.

That said, simple solution:

1 - make the latest list available and mirrored only in trust places like DNS Root Servers.
2 - sign, md5, sha1 sum it.
3 - make the hash of the list available on every package.
4 - If you (or apt) ever gets a new hash, it will know that a new list is out and has to be checked.
5 - Older packages will has older hashes, but it is ok as the new list will say that package still the latest version.

Not an issue for Debian: security.debian.org (0)

Anonymous Coward | more than 5 years ago | (#24145867)

Debian security updates do not come from mirrors. They all come from security.debian.org directly.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...