Hacker News new | past | comments | ask | show | jobs | submit login
Debian Security Advisory: DSA-3025-1 apt (debian.org)
175 points by handsomeransoms on Sept 17, 2014 | hide | past | web | favorite | 64 comments

Honestly, I wonder how many people here are going to worry about apt file signature verification while simultaneously running "bundle install" with a gemfile containing 50 sources including random github HEADs.

Even better when you compare to

curl http://.../ | sh

or god forbid:

curl http://.../ | sudo sh

Well, the major difference being that apt is typically run as superuser, where I would presume you're not using sudo with bundle install. Unless there is an escalation exploit, worst case is that the code trashes your user's home folder.

Still, a valid point for the vast majority of other package managers, including apt. At some point, you have to trust somebody though.

But in almost all cases, the juicy data is in the user account. That's more important than leaking or deleting /bin/ls. :)

Yes if anyone ever got access to my user on my local dev machine, the gig is up. Although we keep production sensitive stuff gpg encrypted and require a password to decrypt, but there is so much information and data in my user home, you don't need super user access to cause damage.

Indeed, and I hadn't thought properly about it until XKCD, as often, shone a bright light on the nonsense that is root password paranoia: http://xkcd.com/1200/

Which leads me to better respect what Ubuntu was doing with the Yama ptrace scope limiting (which prevents you from debugging a running process even if you're the same user, unless you change a /proc/sys var), and why the Weyland developers are wringing their hands on how to properly handle graphical app communication privileges (because currently, X11 allows any process to view any other process's display and events, including keyboard input)

> Unless there is an escalation exploit, worst case is that the code trashes your user's home folder.

Which is where your $PATH is often contained.

If an attacker can modify your $PATH (and has write-access to $HOME), you're pretty much done for.

No, worst case is that the code copies your home folder to some server somewhere and leaves keylogger in your loginscript. Something like that.

Escalation to root from an active admin user account is trivial. Use your imagination.

Bundle problem is real and something MUST be done. However, these 50 sources are open source, usually easily read ruby scripts.

Reading 'apt' source code highly unlikely for the majority of programmers I know.

So... Debian users will need to grab security fixes for `apt-get` using... `apt-get`?

Well, if you want you can always manually download and verify the the packages.

1) Find list of applicable binary packages, for example by taking a look at https://packages.debian.org/source/wheezy/apt

2) Download http://security.debian.org/dists/wheezy/updates/InRelease, and verify the gpg signature against the archive signing key, found in /etc/apt/trusted.gpg alt. in /etc/apt/trusted.gpg.d/*.gpg

3) Download http://security.debian.org/dists/wheezy/updates/main/binary-..., and verify that its sha256 sum matches what you have in your previously downloaded InRelease file.

4 Inside the downloaded Packages.bz2 you'll find the relative paths as well as the sha256 sums of the packages you want to download.

If nothing else this is a good exercise to see how the different pieces fit together.

> does not properly invalidate unauthenticated data (CVE-2014-0488), performs incorrect verification of 304 replies (CVE-2014-0487), does not perform the checksum check when the Acquire::GzipIndexes option is used (CVE-2014-0489) and does not properly perform validation for binary packages downloaded by the apt-get download command (CVE-2014-0490).

There are four specific scenarios that are vulnerable, and none of them appears to be the common scenario of updating packages. Details still sparse, but this seems like a minor security update.

Correct me if I'm wrong, but can't you just download the packages from https://packages.debian.org/wheezy/apt and install them manually using dpkg?

If you know how to verify the signatures properly, that would work. I'm thinking if you don't know that, and if you're willing to do what you just described, you probably don't really care about these CVEs anyway.

Can't you also just verify the sha256 from debian's site? I wrote a script here: https://gist.github.com/shuhaowu/286e6681d6faa473ebb0

sha256 doesn't provide any web-of-trust; if your download is compromised, the sha-sums that you download to verify them could also be compromised in the same way. If the crypto signatures are verified and your installed keyring is genuine (came from a genuine installation media), then you know that the packages you installed (and their signatures) actually came from the Debian project.

That being said, you can try verifying the sha256 and you might catch "them" that way if they didn't think of that.

Well I got the sha256 from the debian site, which is HTTPS secured, which I assume is uncompromised because of this vulnerability, correct? Or am I missing something here?

Yeah that makes sense to me. If you trust ssl. I usually assume that if some three-letter agency wants to hack my computers they are going to find a way and recent history has shown that SSL can be vulnerable too.

I think it's true that without certificate pinning (which you sound like you know about) the various government agencies may easily have people inside your certificate stores that can issue bogus certs. That we've never read of one of these attacks succeeding is further evidence that the conspiracy is working ;)

Yes, and this time it's less secure than just using apt-get.

Original trust is a problem with no possible solution inside a computer.

yeah, can be a pain to get the right dependancies in right order etc though. In this case probably easy enough

Yes, you can definitely do that.

Slight chicken and egg problem there, agreed.

You can check the package signatures for the downloaded debs in /var/cache/apt/archives by following the links for your architecture at the bottom of https://packages.debian.org/wheezy/apt

(You might need to check the rest of the apt-related debs as well. Just replace apt in the URL with the relevant package name and follow the links at the bottom to get the package hashes. If you're tracking sid instead of wheezy then just replace the distribution name in the URL.)

if 'libapt' is not the root cause and if it already is installed on your system , you can probably update safely using `aptitude update`.

libapt has also been updated and the changelog (accessed via aptitude) is the same as for apt itself.

Interestingly both are given "urgency=low" ratings; at least 3 other updates have been medium urgency this year.

Edit: sorry should have said on Ubuntu; I've got libapt-inst1.5:amd64 (1.0.1ubuntu2.3) from trusty/main.

The urgency tag isn't used in Ubuntu, only in Debian.

I was going to say "you should be OK as long as you ..."

But it seems like the CVEs are unavailable, I'm getting 502 Proxy Errors.

It seems like four separate attack vectors are addressed in this update. This all is kind of surprising.

Yeah, I'm having a hard time finding details on the vulnerabilities. A lot of the links in the advisories are broken, and the descriptions on the Mitre CVE pages seem to be awaiting update.

Anybody know how to find better descriptions of these bugs, or the patches that fixed them?

I'm having trouble thinking of a realistic exploit for the first. The second would seem to require not using signing keys which most people have been using for a long time AND the people that are using signing keys (almost everyone) not complaining about bad stuff being substituted in AND the mirror/repo ops not noticing. The third isn't enabled by default and probably doesn't apply to many people. The fourth only applies to people who download and build from source which other than researchers and devs is pretty much no one and is another one of those that relies on everybody not paying attention.

(edited to emphasize that the above isn't some kind of formal pronouncement of The Truth, but it is the logic I used when deciding how to prioritize this situation, which ended up with a conclusion of "not very important, not at all". Your situation not being identical to mine will almost certainly result in a somewhat different conclusion, much as my conclusion would be different if I were in your situation instead of mine.)


It was discovered that APT did not re-verify downloaded files when the If-Modified-Since wasn't met. (CVE-2014-0487)

It was discovered that APT did not invalidate repository data when it switched from an unauthenticated to an authenticated state. (CVE-2014-0488)

It was discovered that the APT Acquire::GzipIndexes option caused APT to skip checksum validation. This issue only applied to Ubuntu 12.04 LTS and Ubuntu 14.04 LTS, and was not enabled by default. (CVE-2014-0489)

It was discovered that APT did not correctly validate signatures when downloading source packages using the download command. This issue only applied to Ubuntu 12.04 LTS and Ubuntu 14.04 LTS. (CVE-2014-0490)

I concur with your analysis of 2-4.


Regarding #1(If-Modified-Since), the vulnerability is that if a hash in the Release file changes, but the file being referred to by the Release file gets served with a 304 response, apt will ignore the updated file and continue to use the old version of the file. even though the old version of the file doesn't match the new hash. An attacker could exploit this to prevent a system from receiving updates, though thankfully it doesn't seem to be possible to exploit this to cause apt to trust an arbitrary package.

Original incorrect speculation below:

Regarding #1 (If-Modified-Since), I'm wondering if perhaps their HTTP client incorrectly accepts a response body with a 304 response (contrary to the HTTP spec)? In that case a malicious server could deliver a file that's blindly trusted as long as it has a status of 304. (This is pure speculation, but I can't think of any other reason this would be a big deal.)

How do you download source packages using the 'download' command? The debian advisory and manpage says that 'download' gives you the binary package, there's another 'apt-get source' command for the source package...

The Ubuntu advisory says "source packages" for some reason. I think it's a typo but it doesn't change the analysis - most people don't use 'apt-get download' to install packages.

Yes, that was a typo. Thanks for spotting it, I have updated the advisory:


you're right about that I didn't even know that 'apt-get download' existed, closest I ever used was 'apt-get source' :)

'apt-get download' is a relatively recent addition.

Here's the relevant changeset in the Debian apt git repo browser: http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=ca7fd7...

Yeah, I was thinking exactly that as my hands typed `apt-get` from muscle-memory.

In the end I decided to close my eyes and hope for the best.

Anyone know how long these bugs have been around or if they have been exploited?

The only secure computer is one that is off.

The only secure computer is one that is not connected to the internet On/Off and some bad person is not physically present.

I can fix off with wake on lan, press on button or just take your internal or external drives.

Is there an easy way to re-validate that previously installed .debs haven't been modified? Perhaps a script to at least check all the debs in the local apt archive cache?

Also, does it really affect regular apt-get upgrades? "apt-get download" isn't a common way to run apt.

Reading your post literally, you're asking how what amounts to mirror operators ensure their mirror is clean, and that's a long story, especially WRT proxies like approx the apt specific proxy not just "real mirrors".

If you're asking more about verifying the files on your install, assuming you trust debsums and its data not to be powned then you'd run debsums -c or whatever. Of course a real attacker would have their highest priority to mess with debsums and its data, hmm. Also debsums is quite slow and resource intensive, so pausing for 10 minutes doesn't mean its crashed or infinite looped, it just means its doing its thing. Finally if you run vanilla and never compile and overwrite your own copy of "whatever" then debsums will work, but if for example you installed debian's apache and then compiled your own apache and overwrote the debian apache binaries (why?), all debsums is going to know is your apache isn't standard debian apache so that doesn't necessarily prove your powned or un powned, it just proves you're not running Debian's apache binary.

Google debsums, and this link will probably help


Whatever you do, don't run "debsums -e" and freak out. At least not without reading the manpage and thinking about it a bit. OK debsums, thanks for letting me know someone modified /etc/ntp.conf, but I think that was me seeing as we have three GPS clocks on the LAN I feel no need to panic. It is an interesting command to use to see how modified a machine's install is. Oh I see you're running stock /etc/detault/ssh and no modifications at all to /etc/sysctl.conf, how interesting.

No, because your attacker could just modify that script, if there is an attacker.

You can write a script yourself, and run it independently of apt, though.

That feel when you see a Debian Security Advisory on the top of HN. Common guys, don't scare me to death. It thought this was going to be heartbleed all over again.

Seeing this almost makes me want to switch back to Slackware for good. Using a Debian based OS has made me lazy; I love the convenience of being able to apt-get whatever I want to install instead of downloading the source and building my own packages. But when you can't even trust the package manager on the most widespread* distro? Basically every single package on my system is now suspect (I did immediately upgrade apt but any damage is already done).

*Speaking in terms of the number of derivatives that also use apt

How did you trust those sites you downloaded the sources from when you used Slackware?

Because it's the software author's site? I don't know how much more trust you could get, beyond only installing the software you write yourself.

Yes, but how to you know it's actually the software author and that the software has not been modified?

If you're not manually checking the PGP-signed SHASUMs of the software you're downloading for slackware, you're not getting any more security the defective apt software we've been running on debian.

Edit: As pointed out by elosius, verifying SSL certs when you download packages would give you some degree of security (and that's what I often end up having to do on Windows), but unless you have access to signed digests from the package author, you won't get any better security than the broken debian apt system.

So then what's the difference between a broken apt not properly validating the source, and the user getting the source from the author, validating it by hand, and then compiling and installing? At least in the latter scenario, the user can be sure it's properly validated.

Personally, I'll choose the latter. Not only is apt a middleman, now it's a compromised middleman. Throw out the middleman and you have only yourself and the author.

You are willing to go through that much effort to download a single package? Sure I love my privacy and security but I have never had a problem on Ubuntu with that. If I ever have to do something particularly sensitive setting up a virtual machine or booting a different OS temporarily would be less effort.

Do I verify signatures when downloading and building from source on Slackware? Yes, I do. Slackware itself comes with nearly all the software I need already. The few programs I need to get beyond that, I always verify hashes. I do this using a script I wrote myself (I'm not a programmer by trade but I can bash out a script, no pun intended). I really don't understand why that's surprising; slackbuilds.org encourages its users to verify source tarballs before compiling, and it's a few seconds of extra work.

The few seconds of manual verification can add up, especially when millions of users do it. That effort could be better spent in auditing a middle-man tool and fixing it for the benefit of all.

The location of the package isn't what makes it safe (i.e. cross-site vulnerabilities and such) but that the package signature matches the published signature from the author. Then it doesn't matter where you download the package. Does slackware do this verification for you?

When did I ever say I wouldn't verify signatures? Does everyone here just assume that because I didn't spell it out that I wouldn't do that?

The only difference between me validating the source and building and installing it myself, and trusting apt to do all that for me, is that apt has been proven to be vulnerable. I'm not going to purposely install non-vetted code on my system, but now it's been proven that apt very well might do that. Again, how is a broken apt more secure than me manually vetting the source, when it comes to my own system?

I think what grandparent means is: did you verify the SSL cert properly, verify the digest of the source code you downloaded to ensure it's authentic, etc…

Well, the thing is, I can do all that by getting the source myself directly from the author. Trusting the apt package maintainer to do that places trust in a third party, and beyond that, it's now obvious that apt for who knows how long, was not trustworthy.

Again, I fail to see how getting the source directly from the author and verifying the integrity of the source package is less secure than getting it from third-parties in binary form?

"I can do all that by getting the source myself directly from the author."

Most people won't, making it a net loss to remove an automated system. Also I'm betting you're not getting the source from the author unless you know the author in meatspace. You're trusting his DVCS (github?) not to be owned and his account not to be owned, then trusting someones gzip / tar program, then trusting their webhost who holds that source code file.

There is the interesting aspect that you probably don't spend all your time on software XYZ, but the package maintainer probably does, so if there is funny business, a distro package maintainer is much more likely to notice than yourself.

Author source repos have been hacked before, they'll be hacked again.

I think what people are sensing, even if they can't put their finger on it, is that you're applying fairly arbitrary standards of what's good and bad here. In reality, security is hard to the point of sheer impossibility regardless of what you do, if you hold everything to equally strict standards. If this leads you to write off apt probably the only consistent thing to do is stop using software entirely, honestly. Nothing is secure to that standard, and even with "certified software" one would forever be wondering about whether the certifiers have their own motives. It seems disingenuous to try to use this as an excuse to slag apt specifically, when with the standards you're using you ought to be yelling about many more things, including your putative solution. (How are you sure your signature checking code wasn't compromised?)

> Author source repos have been hacked before, they'll be hacked again.

Yes, and when that happens it can affect apt packages and manual installations equally.

> I think what people are sensing, even if they can't put their finger on it, is that you're applying fairly arbitrary standards of what's good and bad here.

I think what's going on is that I made the mistake of saying what I'm inclined to do for me, in a forum that often follows a hive mind approach. I'm not bashing apt, nor Debian, all I said was that I'm inclined to go back to doing things the hard way because it's net more secure for me. I realize that in larger numbers, a system like apt (or yum or pacman) is more secure for users en masse, even factoring in temporary lapses like this. But that was never my focus; I was simply indicating that this would be the final push to send me back to familiar territory on my desktop. Everyone jumped on the bandwagon and tried to claim that I said I wouldn't verify source in Slackware, just so they could "win" a discussion and get fake internet points. It's one of the few things about this community that feels immature to me, but then I remind myself that here I'm an old fart surrounded by kids in college or just coming out of it. It's a completely different mindset.

> How are you sure your signature checking code wasn't compromised?

I covered this in another comment, but years ago I wrote a bog-simple script to verify hashes. My code wasn't compromised because it's my code.

I'm not bashing apt vs you can't even trust the package manager on the most widespread distro*

Please don't change the story like this, then insult the people you're talking to by denigrating them ('hive mind', 'immature', 'fake win', 'bandwagon', 'college naifs'). The people responding to you are not just trying to 'win' 'fake internet points', they're trying to counter FUD being spread around package security.

You speak of people being immature, but your whole paragraph there is a sniffy, passive-aggressive swipe.

You speak of changing stories, yet you changed words I typed (I never said the phrases "fake win" nor "college naifs"). You didn't even have to do that to get your point across. That's the kind of immaturity I'm talking about, and you're only proving it further.

While we're on the topic of FUD, did you miss the part where everyone kept insisting I said I didn't verify sources on Slackware, to the point that I had to affirm twice that I do? Anything to make a point, right? Like I said, children being children. It's not a put down, it's simply an observation.

Let me clear this up so there's no confusion: I don't think apt or Debian are bad. I think there is real issue when a glaring security hole like this goes undiscovered for a very long time. That kind of thing makes me want to run back to what I perceive as a safer distro and packaging system, based on my practices when using said system.

As for this community, yes it is indeed mostly college age and slightly older people, who are, to my old mind, "kids". There's nothing wrong with that, and I never said there was, despite your insinuation and word twisting. That's the target audience for a forum attached to a VC firm, as these young minds are the ones launching startups. However, I've lurked here long enough to realize that there is indeed a hive mind approach to conversations, and once a certain set of commenters starts in, the rest of the crowd follows.

My initial post had been voted up several times before the actual FUD on the part of other commenters started, then came the downvote brigade all because the first few replies to me assumed that I didn't validate sources in Slackware builds, hence my opinion was worthless and wrong. By the time I corrected that oversight, the horde had already marched through and nothing I could say from there would change any minds, no matter how rational it was. At one point someone actually tried to say that I was wrong because the author's sources could be poisoned. The fact that that means both the sources I'd grab for a manual build and the sources the apt package maintainer would grab were equally poisoned was lost on that commenter. Logic flew out the window in the rush to prove me wrong.

I know I'll get downvoted to hell for this but I honestly don't give a shit. I come here for news that other sites won't carry, and now I've learned my lesson about saying anything that doesn't mesh with the hive mind. I'll keep my ornery old mouth shut so you bright young minds can keep following the same narrow paths, new ideas be damned. Good evening.

(I never said the phrases "fake win" nor "college naifs")

No, you didn't literally say those phrases, but those were the concepts you were communicating (if you really want to be pedantic, I didn't actually quote you on those; I was listing the concepts). This retreat into "nuh-uh, those weren't my literal words" is a particularly adolescent form of arguing, when you know damn well what you were actually saying.

I'm an old fart too, and I found your comment to be whiny and full of passive-aggression. It was the hypocrisy of that juxtaposed against your calling other people immature that led me to comment.

now I've learned my lesson about saying anything that doesn't mesh with the hive mind

And now for my own turn at immature comments: grow a pair. Comment as you want to. If you get downvoted from time to time, so what? Just don't get all sniffy and whine about 'hive mind' just because your opinion is unpopular. I've complained about the downmod system here for years - check my profile - and there's no need to resort to tired tropes like 'hive mind'. Besides, if you really don't give a shit, then why hand out the derision?

Slackware is hardly that much manual labor, either. You can grab precompiled tarballs from places like AlienBob and Slacky, or you can use the highly interactive, curses-driven sbopkg frontend to install from SlackBuilds in a way that I find is far more awe-striking than any other package manager I've used, if not necessarily that powerful.

There's still plenty of disinfo about it, though. Which is sad, as it is probably the only sane distro left (besides CRUX and Gentoo, perhaps). Patrick Volkerding really is a genius.

I agree completely, it's not that hard at all. Slackware was my proper introduction to the world of GNU/Linux back in the late 90s, and I always end up going back to it. Before the days of sbopkg, I always installed via ./configure -> make -> make install on the source anyway.

Another bonus of going back to Slack would be avoiding the looming systemd switch in Jessie. I'm still on the fence about it; I'm not a conspiracy nut who thinks it's trying to destroy GNU/Linux, but I don't care for how big it's getting either. So far Pat has been good about staying with a traditional "if it ain't broke don't fix it" approach, which I find comforting. Let the other guys deal with bleeding edge! :)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact