Debian Security Advisory - DSA-3025-1 apt - security update

by
Anonymous Coward
in linux on (#2SK4)
Debian has announced a security advisory about its apt-get software, and recommends that you upgrade your apt packages ... with apt, of course.
"It was discovered that APT, the high level package manager, 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)."
This update comes to you courtesy of the IOERROR Twitter account.
Reply 7 comments

Some glaring security holes? (Score: 1)

by zafiro17@pipedot.org on 2014-09-19 14:01 (#2SKX)

I don't code, so am unqualified to comment. But I'll do so anyway :) Seems like these are some pretty glaring security holes; I'm surprised they weren't caught before. Maybe apt works so well that developers don't feel a need to look further into it. Given the number of asshat crackers out there looking for ways to break into VPS boxes and - do what? I don't even know - cracking apt would seem like a clever point of entry.

My VPS registers hundreds and hundreds of brute-force hits every day. Even sshguard fails to stop them as they now bounce your server from multiple IPs simultaneously. Let's say they finally get my server - what would they do with it? Pump out Chinese stock tips and erectile dysfunction spam? Compile themselves a new kernel? What?

Meanwhile, I'm glad people look into this code and fix vulnerabilities like this. Given the number of Ubuntu and Debian servers out there serving webpages, it would seem like a weakness with the potential to do some serious harm.

Re: Some glaring security holes? (Score: 0)

by fnj@pipedot.org on 2014-09-19 21:48 (#2SMK)

I have zero security concern about sshd on my VPS. It's pretty much child's play to make it mathematiocally impossible for them to break in even if they keep trying for billions of years using thousands of bots.
1) Disallow root sshd logins. And never use root or sudo.
2) For admin, have a second UID 0 user account with a long name that no one would ever find in a dictionary. Give it a long, super obscure password and make sure it is set to use SHA512 hashing. Then login to this account using an ssh key which has a long obscure passphrase. Use ssh-agent to manage the passphrase.
3) For ordinary user accounts, use the same name and password policy.

Re: Some glaring security holes? (Score: 1)

by bryan@pipedot.org on 2014-09-21 11:55 (#2SPS)

I disable password authentication entirely in favor of SSH keys. I believe that this is now the default in Ubuntu (since Trusty.) From the Ubuntu wiki:
To be as hard to guess as a normal SSH key, a password would have to contain 634 random letters and numbers.

Re: Some glaring security holes? (Score: 1)

by zafiro17@pipedot.org on 2014-09-21 19:19 (#2SQ6)

That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right?

I'm glad there are no intruders in my apartment, but I'm also tired of them banging on the door. I need a system that paints a big "F U" on the front door and electrifies the doorknob, front walk, and maybe parts of the sidewalk :)

No really, for my front door. Although its parallel in code for my VPS would be nice, too :)

Re: Some glaring security holes? (Score: 1)

by bryan@pipedot.org on 2014-09-22 10:48 (#2SR0)

You can always set up a port knocker. The sshd program normally listens on a port 22, but you can set iptables to drop all packets going to that port until it receives a special "knock" that opens the door to your IP.

Example from DO.

Re: Some glaring security holes? (Score: 1)

by evilviper@pipedot.org on 2014-09-24 07:03 (#2SVX)

That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right?
It does, actually. If you disable password authentication entirely (not just for root or specific users), the server will not provide any way for someone to send it a password. So that's the end of brute-forcing attempts.

(Sorry I'm late to the party)

Re: Some glaring security holes? (Score: 1)

by zafiro17@pipedot.org on 2014-09-27 20:39 (#2SZN)

Hmm, that's useful to know. I'll still have to think about it since I connect to the machine from 3 or 4 desktops over the course of a week (desktop, laptop, work machine, etc.). I'll look into it, because this bullshit is making me tired.

Sure wish there were a legal framework that allowed you to electrocute script kiddies and 'net douchebags.