Debian Security Advisory: DSA-3025-1 apt(debian.org) |
Debian Security Advisory: DSA-3025-1 apt(debian.org) |
Still, a valid point for the vast majority of other package managers, including apt. At some point, you have to trust somebody though.
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.
Reading 'apt' source code highly unlikely for the majority of programmers I know.
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.
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.
Original trust is a problem with no possible solution inside a computer.
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.)
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.
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.
Anybody know how to find better descriptions of these bugs, or the patches that fixed them?
In the end I decided to close my eyes and hope for the best.
I can fix off with wake on lan, press on button or just take your internal or external drives.
Also, does it really affect regular apt-get upgrades? "apt-get download" isn't a common way to run apt.
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
https://packages.debian.org/sid/debsums
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.
You can write a script yourself, and run it independently of apt, though.
*Speaking in terms of the number of derivatives that also use apt
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.
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! :)
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)
That being said, you can try verifying the sha256 and you might catch "them" that way if they didn't think of that.
(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.)
http://www.ubuntu.com/usn/usn-2348-1/
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)
Edit:
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.)
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 ;)
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.
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.
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?
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?
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.
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?)
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.
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.
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.
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?