
Debian Security Advisory: DSA-3025-1 apt - handsomeransoms
https://www.debian.org/security/2014/dsa-3025
======
brockers
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.

~~~
TheCraiggers
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.

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

~~~
swartkrans
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.

~~~
AceJohnny2
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/](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_ )

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

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

~~~
yebyen
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.

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

~~~
yebyen
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.

~~~
pwnna
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?

~~~
yebyen
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 ;)

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

~~~
api
The only secure computer is one that is off.

~~~
baldfat
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.

------
0x0
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.

~~~
VLM
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

[https://packages.debian.org/sid/debsums](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.

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

------
morganvachon
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

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

~~~
morganvachon
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.

~~~
jnbiche
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.

~~~
morganvachon
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.

~~~
JacobEdelman
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.

~~~
morganvachon
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.

~~~
hrjet
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.

