3:35 a.m.
How do i handle a situation where someone, without my knowledge uploads
new sources to one of my projects. It could be a security problem ?
Tim
---------- Forwarded message ---------
From: <notifications(a)fedoraproject.org>
Date: Sun, 27 Dec 2015 at 23:00
Subject: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf
0ae84309cbb6781e7acaf2c1a784f59b yumex-dnf-4.1.6.tar.gz
http://pkgs.fedoraproject.org/lookaside/pkgs/yumex-dnf/yumex-dnf-4.1.6.ta...
--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/timlau.id.fedoraproject.org/...
3:38 a.m.
New subject: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf
Looks like a false alarm, just a scatch build
https://bugzilla.redhat.com/show_bug.cgi?id=1294377
Tim
On Mon, 28 Dec 2015 at 10:38 Tim Lauridsen <tim.lauridsen(a)gmail.com> wrote:
How do i handle a situation where someone, without my knowledge
uploads
new sources to one of my projects. It could be a security problem ?
Tim
---------- Forwarded message ---------
From: <notifications(a)fedoraproject.org>
Date: Sun, 27 Dec 2015 at 23:00
Subject: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf
0ae84309cbb6781e7acaf2c1a784f59b yumex-dnf-4.1.6.tar.gz
http://pkgs.fedoraproject.org/lookaside/pkgs/yumex-dnf/yumex-dnf-4.1.6.ta...
--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/timlau.id.fedoraproject.org/...
4:40 a.m.
New subject: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf
On Mon, Dec 28, 2015 at 09:38:25AM +0000, Tim Lauridsen wrote:
Looks like a false alarm, just a scatch buildÂ
https://bugzilla.redhat.com/show_bug.cgi?id=1294377
Why uploading sources to dist-git for a scratch build?
Pierre
5:54 a.m.
New subject: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf
On Mon, 28 Dec 2015 at 11:41 Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
On Mon, Dec 28, 2015 at 09:38:25AM +0000, Tim Lauridsen wrote:
> Looks like a false alarm, just a scatch buildÂ
> https://bugzilla.redhat.com/show_bug.cgi?id=1294377
Why uploading sources to dist-git for a scratch build?
Properly a mistake by a user there want to make a scratchbuild of the
latest upstream release
not yet in Fedora.
Tim
10:15 p.m.
On 12/28/2015 02:35 AM, Tim Lauridsen wrote:
How do i handle a situation where someone, without my knowledge
uploads
new sources to one of my projects. It could be a security problem ?
Tim
Email the person and ask them?
Check that the md5sum matches upstream?
---------- Forwarded message ---------
From: <notifications(a)fedoraproject.org
<mailto:notifications@fedoraproject.org>>
Date: Sun, 27 Dec 2015 at 23:00
Subject: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf
0ae84309cbb6781e7acaf2c1a784f59b yumex-dnf-4.1.6.tar.gz
http://pkgs.fedoraproject.org/lookaside/pkgs/yumex-dnf/yumex-dnf-4.1.6.ta...
--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/timlau.id.fedoraproject.org/...
--
devel mailing list
devel(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
3:43 a.m.
New subject: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf
On Tue, 29 Dec 2015 21:15:12 -0700, Orion Poplawski wrote:
On 12/28/2015 02:35 AM, Tim Lauridsen wrote:
> How do i handle a situation where someone, without my knowledge uploads
> new sources to one of my projects. It could be a security problem ?
>
> Tim
Email the person and ask them?
Check that the md5sum matches upstream?
Good ideas.
Checking FAS, it looks like it could be a packager who may have
misunderstood the purpose of the lookaside cache or who follows
the update howto without understanding what the individual steps
do.
5:12 a.m.
How do i handle a situation where someone, without my knowledge
uploads
new sources to one of my projects. It could be a security problem ?
Sorry Tim and sorry everyone for this false alarm.
I was playing with fedpkg and I realized I could upload new sources; I thought I could
provide a complete patch (spec+sources) for a couple of bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1282825
https://bugzilla.redhat.com/show_bug.cgi?id=1294377
I didn't realize it could be a security problem at first. As you can see, checksums
match: my intention was to help maintainers and understand better how to use fedpkg
(that's why some days ago I asked on IRC some questions about fedpkg and scratch
builds).
I apologize for the inconvenience.
12:38 p.m.
New subject: security of the lookaside cache (was: frafra uploaded
yumex-dnf-4.1.6.tar.gz for yumex-dnf)
Tim Lauridsen wrote:
How do i handle a situation where someone, without my knowledge
uploads new sources to one of my projects. It could be a security
problem ?
While I trust that Francesco had only good intentions, the general
question remains: Is it possible to modify a package without commit
access by uploading a modified source tarball to the lookaside cache?
Without commit access to Git the attacker couldn't edit the sources
file, so – assuming that everything that uses the lookaside cache
bothers to verify the checksum – the attacker would have to forge a
tarball that has the same MD5 hash as the original. That is an attack
on the second-preimage resistance of MD5.
Practical collision attacks on MD5 have existed for more than a decade,
but to the best of my knowledge no practical second-preimage attack is
known yet. Thus it's probably not practically possible to do this at
this time, except maybe to certain well-funded government agencies
around the world, who may have made further advances attacking MD5 than
the open cryptographic community has.
But still, why are we still using MD5?
Björn Persson
1:08 p.m.
New subject: security of the lookaside cache (was: frafra uploaded
yumex-dnf-4.1.6.tar.gz for yumex-dnf)
On Wed, 30 Dec 2015 19:38:35 +0100
Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
Tim Lauridsen wrote:
> How do i handle a situation where someone, without my knowledge
> uploads new sources to one of my projects. It could be a security
> problem ?
While I trust that Francesco had only good intentions, the general
question remains: Is it possible to modify a package without commit
access by uploading a modified source tarball to the lookaside cache?
Not that I can see.
Without commit access to Git the attacker couldn't edit the
sources
file, so – assuming that everything that uses the lookaside cache
bothers to verify the checksum – the attacker would have to forge a
tarball that has the same MD5 hash as the original. That is an attack
on the second-preimage resistance of MD5.
I don't think even that would work, as you cannot upload new sources
with the same md5sum as an existing upload. It would just tell you
it's already uploaded.
Practical collision attacks on MD5 have existed for more than a
decade, but to the best of my knowledge no practical second-preimage
attack is known yet. Thus it's probably not practically possible to
do this at this time, except maybe to certain well-funded government
agencies around the world, who may have made further advances
attacking MD5 than the open cryptographic community has.
But still, why are we still using MD5?
It's being worked on, we just haven't gotten there yet...
See:
https://fedorahosted.org/rel-eng/ticket/5846
kevin
2:07 p.m.
New subject: security of the lookaside cache
Kevin Fenzi wrote:
On Wed, 30 Dec 2015 19:38:35 +0100
Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
> Without commit access to Git the attacker couldn't edit the sources
> file, so – assuming that everything that uses the lookaside cache
> bothers to verify the checksum – the attacker would have to forge a
> tarball that has the same MD5 hash as the original. That is an
> attack on the second-preimage resistance of MD5.
I don't think even that would work, as you cannot upload new sources
with the same md5sum as an existing upload. It would just tell you
it's already uploaded.
OK, that reduces the attack window as the attacker would have to upload
the malicious tarball after a release has been made upstream but before
the maintainer gets around to upgrading the package.
> But still, why are we still using MD5?
It's being worked on, we just haven't gotten there yet...
See:
https://fedorahosted.org/rel-eng/ticket/5846
Good. Better late than never.
Björn Persson
7:49 p.m.
New subject: security of the lookaside cache
On Wed, 2015-12-30 at 21:07 +0100, Björn Persson wrote:
Kevin Fenzi wrote:
> On Wed, 30 Dec 2015 19:38:35 +0100
> Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
> > Without commit access to Git the attacker couldn't edit the sources
> > file, so – assuming that everything that uses the lookaside cache
> > bothers to verify the checksum – the attacker would have to forge a
> > tarball that has the same MD5 hash as the original. That is an
> > attack on the second-preimage resistance of MD5.
>
> I don't think even that would work, as you cannot upload new sources
> with the same md5sum as an existing upload. It would just tell you
> it's already uploaded.
OK, that reduces the attack window as the attacker would have to upload
the malicious tarball after a release has been made upstream but before
the maintainer gets around to upgrading the package.
And the maintainer would have to not notice that an updated tarball had
already been uploaded. Which is *possible*, because lord knows, we've
all forgotten to run fedpkg new-sources and seen our builds fail and
gone 'oh god, yeah, I forgot to run fedpkg new-sources'. But it's
another thing that has to happen for the attack to succeed, at least.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:09 p.m.
New subject: security of the lookaside cache (was: frafra uploaded
yumex-dnf-4.1.6.tar.gz for yumex-dnf)
On Wed, Dec 30, 2015 at 07:38:35PM +0100, Björn Persson wrote:
Tim Lauridsen wrote:
> How do i handle a situation where someone, without my knowledge
> uploads new sources to one of my projects. It could be a security
> problem ?
While I trust that Francesco had only good intentions, the general
question remains: Is it possible to modify a package without commit
access by uploading a modified source tarball to the lookaside cache?
Without commit access to Git the attacker couldn't edit the sources
file, so – assuming that everything that uses the lookaside cache
bothers to verify the checksum – the attacker would have to forge a
tarball that has the same MD5 hash as the original. That is an attack
on the second-preimage resistance of MD5.
Practical collision attacks on MD5 have existed for more than a decade,
but to the best of my knowledge no practical second-preimage attack is
known yet. Thus it's probably not practically possible to do this at
this time, except maybe to certain well-funded government agencies
around the world, who may have made further advances attacking MD5 than
the open cryptographic community has.
But still, why are we still using MD5?
For the record bochecha has been leading the move away from md5 to sha, making
the changes in such a way that it will give us the flexibility to later change
from sha1 to sha256, sha512 or something else.
The problem being that there are quite a number of places to change (dist-git,
fedpkg...) which all have different upstreams and release cycles.
So all in all, it's in progress but takes some time.
Pierre
5:35 p.m.
New subject: security of the lookaside cache (was: frafra uploaded
yumex-dnf-4.1.6.tar.gz for yumex-dnf)
On Wed, 2015-12-30 at 20:09 +0100, Pierre-Yves Chibon wrote:
On Wed, Dec 30, 2015 at 07:38:35PM +0100, Björn Persson wrote:
> But still, why are we still using MD5?
For the record bochecha has been leading the move away from md5 to
sha, making the changes in such a way that it will give us the
flexibility to later change from sha1 to sha256, sha512 or something
else.
The problem being that there are quite a number of places to change
(dist-git, fedpkg...) which all have different upstreams and release
cycles.
So all in all, it's in progress but takes some time.
That's not the problem any more.
All those places have been changed, and should all be ready for the
switch now.
However, switching means breaking old fedpkg clients: people would have
to update their fedpkg as once we switch the old (i.e current) version
would fail to be able to handle anything non-md5.
The Fedora Releng team decided not to do that breakage at the moment,
and instead bundle it with other changes requiring a breakage, so that
we break things only once rather than several times.
--
Mathieu
3070
days inactive
3078
days old
12 comments
9 participants
participants (9)
-
Adam Williamson -
Björn Persson -
Francesco Frassinelli -
Kevin Fenzi -
Mathieu Bridon -
Michael Schwendt -
Orion Poplawski -
Pierre-Yves Chibon -
Tim Lauridsen