Re: Time to replace MD5?
In article <[EMAIL PROTECTED]> you wrote: > Then they can wget the Release.gpg file, Release file, Packages file > and check each in turn. Their choice. Which is much more complicated than checking a given fingerprint (which is very usual for Advisories) Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
* Steffen Schulz: > If for whatever reason people get untrustworthy, it would be nice to > know as soon as possible, no? Government, Money, .. Well, in this case, you're barking up the wrong tree. What you really want is some kind of audit trail, which might increase confidence in the integrity of the package creation process. A chain of cryptographic hashes which is put in place at the very end of that process is *not* an audit trail. It only secures distribution across the mirror network, and MD5 is currently good enough for that. Using SHA-384 for this purpose might even give a wrong sense of security. > And again, this is just one attack vector. To check the impact and > list the mitigating factors sure is good for employment. Security > design is something else. Security design is mostly about risk analysis. If you built security in from the start, it's unlikely your system will ever make it to the point where you see actual attacks (which means, in most systems: fraud). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
* Steffen Schulz:
> On 070613 at 10:43, Florian Weimer wrote:
>> > AND the fact that it needs to be a valid .deb archive, they are
>> > probably more than strong enough.
>
> This is actually not much of a problem:
>
> http://www.cits.rub.de/MD5Collisions/
>
> One example how to create two files with same hash that act
> differently. Should work with most active content.
The problem is ambiguous content, not the collision. This has been
thoroughly debunked, I don't know why they continue publishing this.
It's easy to exploit their fictional document signing process without
creating an MD5 collision, which strongly suggests ("proves") that the
process itself is flawed.
Since you are located at RUB, could you please make sure that they
correct their analysis?
> Kaminsky did the same with self-extracting executables:
>
> http://www.doxpara.com/md5_someday.pdf
Yeah, but the evil twins must be created *by* *the* *same* *party*.
In the Debian case, this party is already trusted, so the current
attacks make no difference.
>> That, and the "evil twin" package would have to be prepared by the
>> securty team as well, which isn't a relevant scenario (because they
>> could put a backdoor in the original without attacking the hash).
> So apt-get signatures use a secure hash function?
Secure against currently known attacks, yes. And we can distribute a
new hash function to clients pretty easily (something which is quite
unusual).
> With the above results, it would be possible to officially distribute
> nice behaving software but present specific targets with modified
> packages that do evil.
Yeah, right. Guess what? Distributors can do this even without using
MD5 attacks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel-image-2.6.8-4-386 (2.6.8-16sarge7)
On Fri, Jun 15, 2007 at 07:16:00PM +0200, Willi Mann wrote: > However, the advisory is still missing. Yes, so are 3 archs - we're working on it :) If you're curious, you can see the draft dsa text here: svn cat svn://svn.debian.org/svn/kernel-sec/dsa-texts/2.6.8-sarge7 -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel-image-2.6.8-4-386 (2.6.8-16sarge7)
> [EMAIL PROTECTED]:~$ wget -O - \ > http://security.debian.org/dists/sarge/updates/main/binary-i386/Packages.gz > \ > 2> /dev/null | gunzip | grep kernel-image-2.6-386 > Package: kernel-image-2.6-386 > Filename: > pool/updates/main/k/kernel-latest-2.6-i386/kernel-image-2.6-386_101sarge2_i386.deb It was my fault because I checked for kernel-image-2.4 accidently, instead of kernel-image-2.6. Sorry. However, the advisory is still missing. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel-image-2.6.8-4-386 (2.6.8-16sarge7)
On Fri, Jun 15, 2007 at 06:08:08PM +0200, Willi Mann wrote: > Hi! > > Since yesterday, a new kernel for sarge seems to be available. However, > the kernel-image meta package 101sarge2 was only available yesterday. > Today, it's no longer available. > > What has happened here? [EMAIL PROTECTED]:~$ wget -O - \ http://security.debian.org/dists/sarge/updates/main/binary-i386/Packages.gz \ 2> /dev/null | gunzip | grep kernel-image-2.6-386 Package: kernel-image-2.6-386 Filename: pool/updates/main/k/kernel-latest-2.6-i386/kernel-image-2.6-386_101sarge2_i386.deb seems fine to me... -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel-image-2.6.8-4-386 (2.6.8-16sarge7)
On Fri, 2007-06-15 at 18:08 +0200, Willi Mann wrote: > Hi! > > Since yesterday, a new kernel for sarge seems to be available. However, > the kernel-image meta package 101sarge2 was only available yesterday. > Today, it's no longer available. > > What has happened here? Something strange is certainly afoot. I noticed this a few days ago too. No official work or FD notice so I say wait until the package maintainers have issued their notices. -Jim P. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kernel-image-2.6.8-4-386 (2.6.8-16sarge7)
Hi! Since yesterday, a new kernel for sarge seems to be available. However, the kernel-image meta package 101sarge2 was only available yesterday. Today, it's no longer available. What has happened here? Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages being kept back after security notices
On Thu, Jun 14, 2007 at 10:23:28PM +0100, Lesley wrote: > I hope someone can help. With no intervention from me I get the > following on an apt-get upgrade after an apt-get update > > The following packages have been kept back: > icedove openoffice.org openoffice.org-base openoffice.org-calc > openoffice.org-core openoffice.org-draw openoffice.org-evolution > openoffice.org-gcj > openoffice.org-gtk openoffice.org-impress openoffice.org-java-common > openoffice.org-math openoffice.org-writer python-uno > > after > [DSA 1307-1] New OpenOffice.org packages fix arbitrary code execution > and > [DSA 1305-1] New icedove packages fix several vulnerabilities > > > Why would these packages be kept back? As per http://lists.debian.org/debian-security/2007/06/msg00042.html you need to use apt-get dist-upgrade for this particular upgrade, as it was necessary to change a library version OpenOffice.org depended on. Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
Bernd Eckenfels <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]> you wrote: >> I don't understand why DSAs for etch include md5sums and manual upgrade >> instructions at all. Apt can verify the checksum and gpg signature and >> handle the upgrade after all, and probably more securely than the >> average user following the manual instructions. > > Because open source is all about choice. There might be admins using dpkg -i > or security officers who build their local mirrors manually. Then they can wget the Release.gpg file, Release file, Packages file and check each in turn. Their choice. As for local mirrors: debmirror and reprepro already check the Release.gpg file if wanted and anybody using something else to mirror should do so too. So both aren't really good arguments to complicate the mails. > Gruss > Bernd MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
