On Thu, Jun 12, 2014 at 01:06:28AM +0200, Christoph Anton Mitterer wrote: > In my opinion this is really some horrible bug... probably it could have > been very easily found by others, and we have no idea whether it was > exploited already or not. Probably yes. Someone in the last ~11 years could have, but that nobody did tells you a lot about how many people actively work on what so many people seem to assume just has to work and complain loudly if it doesn't in the way it always was (assumed to be)… so, to get anything useful out of this: Should we do a kickstarter now or wait for a libreapt fork? > Anyone who believed in getting trusted sources might have been attacked > with forged packages, and even the plain build of such package might > have undermined users' security integrity. Worst case. In practice you will have installed build-dependencies before which has resulted in a error for those, which should have been enough for you to recognise that something fishy goes on. It is at least what all automatic builders will run into. Assuming of course you don't ignore such errors which many users/scripts happily do… Also, keep in mind that the chain is broken at the Release -> Sources level, not at the Sources -> tarball level, so if you ship modified tarballs to your target you have to also ship a modified Sources file. For your attack to be (always) successful, you need a full-sources mirror on which you modify all tarballs, so that you can build a valid Sources file. You can't just build your attack tarball on demand as the hash (and filesize) isn't going to match with what Sources declares. (assuming you aren't good at pre-imaging, but then, why do you bother with this one here?) Combine that with the problems of being a good MITM in general and you might understand why my heart isn't bleeding that much about this particular bug. We had worse and nobody really cared… > It's really saddening to see that such an issue could slip through, > especially when I've personally started already a few threads on > debian-devel about the security of secure APT. > The most recent one was IIRC: > https://lists.debian.org/debian-devel/2012/03/msg00549.html > but I've had one before, I think. What is really sad is that many people keep talking about how much more secure everything should be but don't do the smallest bit of work to make it happen or even do a basic level of research themselves. So instead of answering all your questions, I will instead leave them unanswered and say: Go on and check for yourself! You shouldn't trust a random guy like me anyway and if that leads to even one person contributing to apt (or the security team or anything else really) in this area, we have a phenomenal massive increase in manpower … (for apt in the 50% ballpark!) > - I think per default APT should refuse to work with unsigned > repos/packages. One should really need some configuration switch or > option that allows this. I will comment this one though: Michael wanted to look into this for a while now. The plan I was suggesting was something like jessie: support-unauth=true by default, jessie+1: support-unauth=false by default, jessie+2: gone. We will see if this can be implemented at all. Contributions welcome as always. > I don't think it's a big issue, since all the major repos are signed and > even the "end-user" tools to make own repos (like debarchiver) support > signing. Think again. People do it all the time. It is the default mode of operation for plugging in repos into builders for example. If you are bored, just search for the usage of --allow-unauthenticated. I half-jokingly mentioned with the plan last time that a bunker is nearby, so I would be safe; half-jokingly as at least I got murder threats for far less. I doubt it will be any different with this "not big issue". So be careful with what you assume to be simple and uncontroversial. See also xkcd#1172. Some usecases can be transitioned to [trusted=yes] probably, but I am not sure we really gain that much this way (as it makes things actually worse from a security standpoint) so we really shouldn't press the "security: don't care" crowd in this direction. Hence the slow ride-plan. > People should simply be taught to not use unsigned repos... Yeah. I will try my luck with world peace first though. Might be easier… But I am a naive kid. 5 years ago I wondered why a small bug – which even I could provide a patch for – wasn't fixed. Now I wonder how the "team" manages to keep up with reading bugs at all; but its the same for many other "Debian: native" packages. aka: It took me a while to understand what "no upstream" really means … Best regards David Kalnischkies P.S.: Dropping security@, bug@ and everyone else in Reply-To as this chit-chat thread is just noise for them. Please don't pick up cc's at random … If you want to /work/ on anything you could move to deity@ as already suggested. Otherwise lets just talk here… (and no, you don't have to cc me either)
Attachment:
signature.asc
Description: Digital signature