Flaws found in BSD, Linux software updaters

[revzalot]

Interesting read here:

http://news.zdnet.co.uk/security/0,1...9446765,00.htm

[18Googol2]

The researchers found that it was not a problem to set up a malicious mirror. They created a fake administrator and company name and leased a server from a hosting provider, and were able to get the fake mirror listed officially by the distributions Ubuntu, Fedora, OpenSuse, CentOS and Debian.

Technically, I dont get it.

[Carpetsmoker]

I don't get it either, as far as I know, the outlined problems in this article do not affect FreeBSD ports ... Maybe there are other issues in FreeBSD?

[hunteronline]

http://www.cs.arizona.edu/people/jus...-managers.html

It doesn't actually say FreeBsd, just "We examined ten popular package managers (APT, YUM, YaST, etc.) for Linux and BSD systems and found vulnerabilities in all of them."

[ninjatux]

I think it's referring to dated packages in mirrors being insecure.

[hunteronline]

No, it's saying a malicious mirror can deliver old packages with known security flaws when you update and them use the known flaws to attack your machine or, network.

[18Googol2]

The 2nd url clears everything up. Its more social engineering threat to me

[TerryP]

my personal opinion


It's all a crock full of buffalo pucky, the link posted by hunteronline is the same one I saw on slashdot when following my RSS feeds.


The reply problem is a valid concern because if you do get an attacker with enough access to your system, they can tamper with your system files -- never mind mucking with package management enough to send you outdated files.


If any software used to decide what is up to date and what is not is up to date can't tell the difference. There best be a carefully made 'tainted' package that appears to be new, a bug in the code, or some really stupid people IMHO.


Mirror control? Well if the people can't be bothered to make sure that the mirrors they are promoting are as valid as the checksums and other security methods YOU should be publishing to ensure validity of packages and metadata. Then you deserve to have all of your users file your distribution under /dev/null and find one that doesn't do it half assed.


FreeBSD ports uses md5 and sha256 checksums and if memory serves it also does size check on the distfile as part of validating it. To side step that an attacker needs to compromise the local system and adjust the distinfo or compromise the data being received during a portsnap/csup/cvs of the ports tree, the source of the distinfo, go main in the middle, or trick a moron with proper access into doing or allowing it to be done manually.


This is one reason I like portsnap, updates are signed -- I don't know if csup/cvsup supports that.


The first rule of security, use your freaking brain cells. Like the lump of gray matter roughly three feet above your buttocks. A brain is _such_ a terrible thing to waste!

Things You Can Do Today:

    * Use repositories you trust. Use only mirrors that belong to reputable organizations. Don't randomly choose mirrors, even from official lists. The official lists of public repositories often contain many superficially verified mirrors.

If you can't trust the mirror you shouldn't be using it, if the mirror can not authenticate itself to you, there is a problem in the design of your package management system or your system configuration.

    * Manually update your systems (and local mirror caches). Know when package updates become available and what the versions should be. Manually verify and install the updated packages (or add them to your local mirror cache that your systems update from) rather than relying on automated updates. We have observed mirrors many months out of date for some distributions, so you should check periodically that your mirror is being updated.

If your paid to take care of the box, you should know when software updates are available to any core services (such as mysql or sendmail) before they hit your distribution's repository.

If the mirror is out of date, someoneshould bloody well notice it huh?

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

If the 'metadata' has no way of being validated don't use it, if security is paramount.

    * Use HTTPS for mirror communication. Unfortunately, this is generally only available with paid support services (and only protects you against man-in-the-middle attacks, not malicious mirrors). However, by running a distribution with HTTPS support on their mirrors, a man-in-the-middle attacker cannot easily launch an attack as though it were a mirror.

nice idea, I wonder how much stuff is just done via ftp?

In the future:

[/code]
* Use package managers that sign repository metadata. Unsigned repository metadata gives malicious parties more leverage in their attacks.
[/code]

the package management *system* is responsible for this, not the package manager program necessarily but it must be done within the system somewhere !

    * Use package managers that implement metadata expiration. If there is no way in a package manager for metadata to ever expire, replay attacks will be able to go unnoticed.

This is a good idea, one up would be allowing the system administrator to set an expiration date IMHO. Even if the whole dang thing is done by a combination of dates and public key cryptography.

    * Use distributions that properly make use of the package manager's security features. If a distribution doesn't sign repository metadata or expire these signed files even though the package manager supports doing so, it doesn't help you stay secure.

If the distribution doesn't do jack crap, find another that does and shout loudly.



*disclaimer*

I can be a very picky son of a biscuit eater when it comes to *trying* for a correct implementation instead of living with a forever half assed approach.




I appologize if I have offended anyone.