Signed changes upload replay attack vulnerability

If Soyuz accepts the same signed build request twice sounds like a bug in and of itself (a replay attack vulnerability).

While that is the case, we definitely shouldn't be publishing links to the files.

Hi Stefan,

We could continue to present the changesfile link only for users with edit permissions in the PPA in question, this way correct "replays" could continue to be performed collaboratively inside team PPAs.

I don't feel strong about the utility of this use case, just want to check if we are heading toward the primary objective which is presenting as much useful information as we can without exposing vulnerabilities.

Hi Celso,

Am Montag, 12. November 2007 15:26 schrieb Celso Providelo:
> Hi Stefan,
>
> We could continue to present the changesfile link only for users with
> edit permissions in the PPA in question, this way correct "replays"
> could continue to be performed collaboratively inside team PPAs.

I guess that might lead to problems as well: If a team member can upload to
given PPA but not to universe for example, while another team member can,
this could still get abused (e.g. having a PPA set up where both MOTUs and
contributors can upload).

After a short discussion on #lp at Saturday evening, it looks like the real
solution would be to have soyuz not accept two identical changes files in a
row. That way the ticket functionality of changes files would be restored.
Since there is a date stamp in a signature, two identical uploads were still
ok (because the signature would then differ). Of course once a PPAs allow the
same distribution names as Debian (or a derivate) there could still arise
problems, but I guess that shouldn't happen in the first place anyways.

Thanks,
    Stefan.

Ok, let's sort this with the simplest solution we have, a "damage-control" task. I will purge the changesfile reference from the UI for now.

Legit "replays" from PPA to ubuntu primary archive or to another PPA will be possible in the next milestone code via request w/o requiring a new upload. We will discuss further details with MOTU-team before release.

I think that the unique_changesfile suggestion is miss-conceptual, because it mixes distribution permissions with content uniqueness, but it requires further thinking.

Let me correct myself, the "damage-control" task will consist of requiring Admin permission to view the changesfile link. I decided to do this because it will result in removing less code that might become necessary again in the future.

Hi Celso,

Am Freitag 16 November 2007 20:33:15 schrieb Celso Providelo:
> Ok, let's sort this with the simplest solution we have, a "damage-
> control" task. I will purge the changesfile reference from the UI for
> now.

Excellent, thanks a lot!

>
> Legit "replays" from PPA to ubuntu primary archive or to another PPA
> will be possible in the next milestone code via request w/o requiring a
> new upload. We will discuss further details with MOTU-team before
> release.

Great. I guess also core-devs might be interested in this ;).

>
> I think that the unique_changesfile suggestion is miss-conceptual,
> because it mixes distribution permissions with content uniqueness, but
> it requires further thinking.

Well, for a bit-identical source package, it's not necessary to have an
identical .changes-file. If I'd want to upload the same thing first to a PPA,
and then to the archive, I could easily sign the very same .changes file
again with debsign, which results in a different signature and an
content-wise unchanged .changes file.

Hope this helps you with thinking ;).

Cheers and thanks a lot,
    Stefan.

RF 5200 hides the changesfile link, we will design a effective way to prevent replay-attacks during the next milestone.

According to duplicate bug 177113, it is still quite easy to guess the URL to the changes file on the librarian even though we don't link to it.

Since all the files from the upload are stored in the librarian sequentially, they are likely to get consecutive IDs. As the filename is known, it doesn't take many guesses to find what the LibraryFileAlias ID is.

Re-targeting to 1.2.1 to complete the work.

Any news on this one? The problem came up in discussion on #launchpad again today, with someone asking whether other people could see the changes file links on his PPA page, and whether that would allow others to re-upload his packages to Ubuntu's main repository.

I guess https://blueprints.launchpad.net/soyuz/+spec/ssh-package-upload might mitigate the problem for Ubuntu developers, but might it still be a problem for users who also happen to be Debian developers?

James Henstridge ha scritto:
> I guess https://blueprints.launchpad.net/soyuz/+spec/ssh-package-upload
> might mitigate the problem for Ubuntu developers, but might it still be
> a problem for users who also happen to be Debian developers?

I don't think this will harm Debian. We use different suites (e.g.
intrepid against unstable) and uploads for an unknown suite should be
rejected by dak.

Hi,

almost one year later, I've had to discover that this security vulnerability is still not fixed, as I could easily guess the .changes file location of a PPA.

Please fix this within the next two weeks, otherwise I feel inclined to make this grave security bug public together with proof-of-concept methods how to exploit it.

Cheers,
   Stefan.

RF 6836

Changes files will no longer have signatures on them.

The old changes files are still in the librarian, but they will be garbage collected in a day or two.