robbat2: (Default)

Those that have followed me for a while might have seen me previously complain at journalism that's misleading, wrong, or outright fictitious. Now I've got another case...
This article by Ed Bott at ZDNet:
Linux infection proves Windows malware monopoly is over; Gentoo ships backdoor? [updated]

The article was first published 2010/06/12 20:37 UTC.
It claims to be "worse" when updated at 2010/06/14 19:30 UTC.

Gentoo had a revision bump to a known good copy of the tarball at 2010/06/12 16:34 UTC (using a different filename, and verified against the GPG signature provided by upstream), so it was ALREADY fixed when the article was published. The old revision was explicitly removed at 2010/06/12 21:18 UTC.
Commit data for fixes:
Changes for unrealircd-3.2.8.1-r1.ebuild
Changes for unrealircd-3.2.8.1.ebuild

The trojaned tarball was then removed from the Gentoo master mirror at 2010/06/13 08:00 UTC, about 11 hours after the article was published. It would have been sooner, but it was a matter of bad timing.

Gentoo bug 323691.

The article also claims: "There’s a great deal of comment in the Talkback section of this post about how official repositories can be trusted. It appears that system broke down thoroughly in this case."
This claim is bogus. The developer that updated the package made perhaps a mistake in trusting that the upstream had not been tampered with. However, in lacking anything to verify against (the upstream apparently did not sign releases at that point), he couldn't have detected the backdoor except by manual inspection of all the code. He downloaded the package AFTER it had been tampered with (2009/11/11 I believe), so he never saw the tamper-free version either.

The entire point of the Gentoo Manifests are to ensure that OUR mirrors are not the point where a compromise is introduced. We can detect upstream changes by this same mechanism, but they mostly tend to be upstream deciding to 'fix' something without bumping the version number. In this regard, they functioned perfectly.

P.S. I'm not saying the existing Gentoo mirroring is perfect either, see my prior writings on tree-signing, and the "Attacks on Package Manager" papers by Cappos et al., which are blocked only with the full tree-signing system.

robbat2: (Default)

Having my bike stolen has made me wonder about locks more. Defeating most forms of bike locks are trivially easy with some lateral thinking.

This was my lock:

Lock properties and attacks against
key-based
bumpkey (given a suitable blank or other key of same style), pick the lock, drill or freeze the lock (either LN2 or just adding in warm water on a day that's below freezing)
combination-based
guess or shoulder-surf the combination
Cable/Chain
Large bolt cutters, wire cutters or hacksaw
U-Lock/D-Lock
Use a jack inside the arms to apply outward force

Any other bicycle lock types or different attacks that you can think of? Any way to effectively defeat one of more of the above attacks? From a security perspective, we need to consider not only the permitted attacks, but all possible attacks.

In my case, they either defeated my combination (probably by shoulder-surfing), or just used some form of cutting attack. Since the lock wasn't left behind, I suspect the former more than the latter.

robbat2: (Default)

So my carry-on laptop backpack got a full going-over because of a little folding tripod that apparently looked weird on the scanner...

And they saw and removed the small zipties that I use for securing my suitcase normally, claiming that I could use them to tie people up.

Nevermind the 6ft ethernet cable, or the laptop cable, I was going to be able to tie somebody up with a couple of zip-ties, each 5cm in length, with a width of less than 4mm.

The American TSA side has never complained about them, and now on a Canadian domestic flight they did. Just simply crazy.

robbat2: (Default)

So on Slashdot today, there was a link to the latest research into Package manager security. Specifically, their focus was on defeating signed packages by use of malicious mirrors and replay attacks of signed content. Recording the source of client requests, and possibly denying specific security updates (having an older tree that doesn't contain the security updates).

This plays into some of my long-ongoing tree-signing research in Gentoo. The GLEPs with the exception of 02 and 03 have been mailed to the GLEP editors as well as the portage-dev mailing list, and will be going to the gentoo-dev mailing list after the GLEP editors have reviewed them.

For dealing with the new issues raised by Cappos et al, at Gentoo we are really lucky to have our own infra maintained hardened rotation of mirrors at rsync://rsync.gentoo.org/ in addition to the community mirrors at rsync://rsync$N.$CC.gentoo.org/. Nobody using just the infra-maintained mirrors (barring MITM attacks) would be vulnerable to the new attacks described by Cappos, however those using a community-maintained mirror could be.

Using the main mirrors for new signing purposes, this will enable us to deliver the new MetaManifests reliably via our own infrastructure, even when the user has a community mirror for their actual tree content. The actual changes to the GLEP for this weren't very big at all. Just a timestamp header inside the signed area, as well as distributing the MetaManifests via a trusted medium.

As a minor side note on the infra-maintained rsync.gentoo.org rotation, this would be a good time to consider sponsering a box to Gentoo for that purpose. Each of the 5 existing boxes in the rotation does 50-65GiB of traffic every day - averaging to 6.5Mbit/sec, over a 24-hour period. These boxes are bandwidth, memory and CPU intensive, however they don't hit disk very hard (we serve the trees directly from memory). 4GiB RAM, 2+ 64-bit processors (single core or dual core is fine), ~16GiB of disk (optional: software RAID1 is nice for avoiding downtime, and fancy fast disks aren't needed). We need a serial console or KVM to install it securely - you just boot the box to a livecd, get the access details to infra, we install it from there with our own stage4 tarball that links into cfengine. The machine continues to be owned by the sponsor, in your data centre.

robbat2: (Default)

Up until recently, I had thought most Gentoo users and developers to be adults, who made sensible choices in their actions (but not always their words). This may be generalized to acting professionally. I am saddened to report on the ongoing degradation of the community in this regard, and how infra will deal with their side of it.

I've been with the infrastructure team in general for a very long time, however, up until April 2007, I was only the CVS administrator, and had no roles nor access outside of that. Since then, I stepped in as an extra sysadmin, and I've ended up as one of the operational leads, which still means I do most of the work, I just get to make the choices about it too. While the 'old' infra were in some cases called tyrants, dictators, cabals, and other nasty things, we as the 'new infra' hoped to change this view.

We're charged with a lot for developers and users: procuring machines to run them on, maintaining them, developing new services, troubling some user and developer issues (eg: cvs/mirrors) and more.

For myself, in addition to the CVS/SVN/Git services that grew out of my CVS administration, I presently maintain LDAP, Lists and Bugzilla. I have also been the infra liaison to the releng team since 2007.0.

The various VCS and LDAP services are only of primary concern to developers, because extremely few users interact directly with them. However, Bugzilla and Lists are used by significantly more users than developers, and the interactions show.

All messages to mailing lists with 'unsubscribe' in the subject line get moderation and passed to me, and a great many of them are in the realm of blunt and abusive - usually on generic-sounding email accounts that have changed ownership to clueless people. There's also the fun of keeping the spam off (see my recent post to the mlmmj list, of which I should possibly blog about). That's the mundane side. There's also moderation of the actual moderated announcement lists, and tracing mis-delivered list bouncemail as it gets reported. Lastly, and perhaps most important to some, we are held accountable to userrel and devrel for enacting list bans.

Bugzilla gets less direct abuse, however when it happens, it's usually quite flagrant. jakub used to complain to me once or twice a month about users refusing to take no for an answer, and repeatedly filing duplicates, or deleting entire CC lists, or spamming a bug. Since his absence, I've caught less of these early on, simply because he basically read every bug that was filed, and I don't have the time for that (yes, I'd like him back, he did a good job). Bots that ignore robots.txt are a hassle, but are mostly manageable.

For developer issues, we haven't been offering executable homedirs for several years, since some former developers tried running BOINC, and various servers. It seems however that there has never been any codified warning, merely action on a case-by-case basis.

As of today, we're formalizing the handling of this. All infra-maintained machines either already, or will shortly have an AUP banner as follows:

 Any or all uses of this system and all files on this system may be
 intercepted, monitored, recorded, copied, audited, inspected, and
 disclosed to authorized site personnel, as well as authorized officials
 of federal law enforcement agencies, both domestic and foreign. By 
 using this system, the user consents to such interception, monitoring,
 recording, copying, auditing, inspection, and disclosure at the
 discretion of authorized site personnel. Use of this system constitutes
 consent to security monitoring and testing. All activity is logged with
 your host name and IP address. Unauthorized or improper use of this
 system may result in civil and criminal penalties. By continuing to use
 this system you indicate your awareness of and consent to these terms
 and conditions of use. -- Gentoo Linux Infrastructure Admins.

To make it more concise without the legalese: If you abuse a Gentoo infrastructure system, we have no compunctions about kicking your ass and handing you to the suitable authorities (userrel, devrel, $GOV_AUTHORITY).

What does this not mean? Aside from being proactive about patching security issues, we are not intended, nor do have no plans to target people that some of our group don't get along with - we're meant to be accountable and responsible to other authorities in Gentoo. We'll collect the evidence (logging) and execute you (retirement), but somebody else (devrel) gets to sentence you - the only exceptions to this are preemptive actions where we consider security to be at risk.

On the matter of logging, we aren't the Stasi either, we have far better things to do than babysit logs, and we've been logging a lot longer than I was ever even a Gentoo developer. Some former developers and infra folk automated the log analysis, so the only time we really need to look is when something has been brought to our direct attention and needs logs to back it up. The most common uses for the logs are finding abusive users and bots against rsync and bugzilla, plus doing audits after (in)security events.

robbat2: (Default)

Recently I've been digging around in the annuls of Gentoo history, working on what will hopefully be the final tree-signing proposal before it actually becomes a full reality. During the midst of this, Stuart came up to me in #gentoo-dev:

<Stuart> robbat2: btw, did you see this week's LWN?
<Stuart> robbat2: the one of using Google Code to find PHP apps that are vulnerable to allow_url_fopen attacks
<Stuart> robbat2: you were right, all those years ago. just wanted to tell you that.

I wasn't the first to come up with the idea, the BSD ports folk were talking about it around the same time we were in mid-July 2003, and I was aware of their discussion, but I believe that Gentoo was the first Linux distribution to make this jump in turning it off. I took a lot of flak at the time for breaking many PHP applications in the name of security, but history has now shown that allow_url_fopen is a very common PHP exploit, and with the advent of Google Code, many sites may now considerably more vulnerable - and all of this could have been mostly avoided a long time ago if PHP had just included a taint mode from the start...

I hadn't read LWN yet, it's only been out a few hours, yet here the article is: "Remote file inclusion vulnerabilities". Stuart also posted a link back into the murky depths of the Gentoo CVS, with a commit I made in July 2003, that turned off allow_url_fopen by default in Gentoo.

May 2017

S M T W T F S
 123456
78910111213
141516171819 20
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags