Re: Facilitating external repositories
On Sat, Aug 15, 2015 at 12:47:42PM +0200, David Kalnischkies wrote:
> > I think my working assumption is "anyone" can register, and it's done
> > automatically. If you want to ensure the URL is owned by the register,
> > you could use a dummy DNS record ("please add
> > extrepo-de684554ae0c3440.example.org CNAME extrepos.debian.net.
> > to your DNS").
> "Srsly"? Until now it sounded very open, but DNS records are far from
> being available for everyone (and far from being secured) beside that
> there can be multiple archives on the same domain. Try again.
Like I said, my working assumption is anyone can register and it's done
automatically, ie no check at all. You wanted something harder, not me :)
A less obstruse check would be:
- is the nominated key the signing key for the repo's Release file?
- can the person sign an "extrepo request" with that signing key?
which should be about sufficient to demonstrate control of the domain
and key.
> > > > > > Or did you mean that the DD signs the sources.list file directly? Well,
> > > > > > then my key isn't usable for that right now, but in exchange the DD
> > > > > > might have a slight problem in assuring the correctness of what he is
> > > > > > signing: I am the owner of example.org/debian. Trust me.
> > > > I'm not sure this is a problem -- if you're not the owner of
> > > > example.org/debian, then the files I download from there won't have your
> > > > signature. If they do have your signature, then it's just the question
> > > > of whether I trust your random repo, and I can't figure that out just
> > > > from knowing who you are.
> > > … I was thinking man-in-the-middle here. If I can register
> > > example.org/debian with a key of my choosing I can do really bad things,
> > > especially if example.org is the domain of a Debian mirror and I manage
> > > to trick people into adding this e.g. by claiming that this is a faster
> > > mirror…
> […]
> > If you put in a /different/ key and go to the trouble of intercepting
> > some users' traffic to example.org, things look slightly different:
> […]
> > There's a few problems with doing that:
> > a) anybody whose traffic to example.org you can't intercept will
> > get an error if they check that repo against the nominated signing key.
> > if extrepos.d.n does minimal sanity checking before adding a repo,
> > this makes this attack a non-starter afaics.
> So, let me get this straight: The reason we need extrepo.d.o is because
> there could be an all consuming man-in-the-middle exchanging the
> description as well as the download of the archive key with something of
> his own choosing, but if we have extrepo.d.o this is suddently no longer
> a problem because it is too unlikely that there is such a man-in-the-
> middle.
Obviously not.
Here's how you currently setup an external repo as securely as possible:
1. You hear about a cool repo from somewhere, and are told to go to
https://example.org/debian/README.html for more instructions.
2. You read that page, and obtain a line to add to sources.list and
a key to add to apt-key.
3. You (maybe) look at the key to see if it's signed by someone you
know, and doesn't look shady.
4. You add the key and sources.list entry, and run apt to install the
packages.
If https and example.org are secure, or if you are able to verify the
key using the web of trust, this is fine (although it requires a bit of
effort).
If neither of those are reliable (because you've got a Lenovo laptop
so anyone can fake SSL on you or just because its an http:// url not an
https:// one; and because you don't understand gpg so don't know about
the web of trust, or because someone in the Debian keyring isn't 100%
perfect, eg), then there's a MITM attack: I capture your traffic to
example.org, replace the README, key and repo, and you're stuck.
That's the MITM attack that's avoidable.
There's an entirly separate attack that's fundamental to external repos:
I make an external repo of my own, pretend that it's good, get people
to install from it, but actually upload bad things into it. In that case
I'm not "in the middle" though, I'm an endpoint.
With extrepos as I describe them, the steps are:
1. You hear about a cool repo from somewhere, and are told to just
get the example-abc123 repo.
2. You run "extrepo add example-abc123", and run apt to install the
packages.
extrepo uses a Debian signed certificate linking example-abc123 to a
unique key and url, so that anyone who tries to get that repo is pointing
to the same place.
If you want to tell people to go to a different repo -- example-123abc
say, that's fine; but allowing that is a required feature. Likewise,
you could MITM the forums that are raving about what a great repo
example-abc123 is, and make them look like they're raving about
example-123abc, but I don't think that's avoidable.
> > b) if someone's trying to install a PPA for secured-ssh, why would
> > they go through extrepos?
> Because editing sources.list is hard and running 'extrepo add
> ppa-whatever-16734' is easy?
If there's no special interface for PPAs (like apt-add-repository ppa:blah
for Ubuntu), extrepo could have one I expect.
> > c) if you've gotten someone to install your extrepo, and they'll agree to
> > install things signed by your key, why not just point them directly
> > at a server you control? if you do that, you can be much nastier,
> > eg by serving a real secured ssh to most people, and a vulnerable
> > ssh only to people you're trying to hack.
> >
> > Running an extrepo by someone you don't trust at all is still crazy,
> > as installing software written by someone you don't trust at all is crazy.
> > The improvement is for the case where:
> >
> > - you trust "Debian"
> > - you trust whoever wrote/packaged the software by reputation
> > - you don't have direct communication with the software author/packager,
> > or their public key, etc
>
> Which is exactly the problem. You have moved the problem of being unable
> to establish a trust path from user to archive, to extrepo to archive
No, extrepo.debian.net doesn't need to trust the repo provider to any
degree. The trust path is:
user trusts "example-123abc" repo for some reason
user/repo provider trusts extrepos.debian.net to provide same information
about example-123abc to everyone, authenticated via public key
user trusts Debian archive to provide extrepos.debian.net public key
The connection between the user and the repo provider is via the unique
name example-123abc. That's far fewer bits to match up than an entire
public key, and easily shareable on forums etc, so seems a lot better
than the state of the art.
> So again, lets say I am registering example.org/debian as repository
> with key 0xABCDEF, how do you ensure that I am
First, I don't /care/ who you are. Who registers the extrepo doesn't
matter as far as the trustpath is concerned.
> a) the owner of example.org/debian,
> b) the owner of 0xABCDEF
The owner of key 0xABCDEF12 is whoever can sign things with it. The owner
of example.org/debian is whoever can put things in it. If 0xABCDEF12
has signed example.org/debian/dists/foo/InRelease then they've already
verified both things. But, again, that's not actually necessary.
> c) this key is really for this archive and
That's something apt checks: if you install the extrepo and what you
get isn't signed by the corresponding key, it will error out.
> d) that while I say I am the master of the known
> universe (or more realistically, this is the Davids APT ppa), how do you
> going to verify that I am who I am saying I am.
I don't care if you are who you say you are.
You attack model seems to be:
1) Alice sets up a repo on example.org/alice-debs/ and signs it with
her key.
2) Mallory registers this repo as example-aaa111 on extrepos, with
Alice's key (which he doesn't control) and Alice's URL (which he
doesn't have write access to)
3) Bob adds example-aaa111 to his system, and installs stuff from it.
But nothing bad happens in this scenario -- Bob's trusting Alice's key,
not Mallory's. If Mallory MITM's Alice and Bob, he doesn't have access
to Alice's key, so apt will error out if he tries modifying the repo. If
he just replays old repo states, apt will eventually give an error when
whatever date Alice set as Valid-Until hits.
> > Havng an extrepo lets the software author/packager announce an extrepo id,
> > at which point any Debian user can obtain the same extrepo sources.list
> > entry. (There's still a potential mitm in *obtaining* the extrepo
> > id, but that's more easily mitigated the shorter it is)
> Or as you describe it here you are not checking at all at which point
> there will be 300 repositories all claiming to be from me so that users
> still somehow have to figure out how to contact me personally in
> a secure way so I can tell them which one is really from me. And suprise
> suprise, that is the very same situation we are in at the moment, so
> what was it again we have solved?
Why do you think they want a repo from you in the first place?
- they already know you personally, in real life or online, and have a
trust path with you. In that case, they get the repo id from you using
that trust path, and "example-123abc" is a lot easier than a URL and a
public key to pass along on whatever trust path that is.
- they heard about it on a random mailing list or web forum. In that case
they can just ask what the extrepo id is on the same forum, but
hopefully the extrepo id was included already: "Just use David's new
apt stuff from extrepo:apt-555999". Trusting strangers on the Internet
already dooms you a bit, but if you're going to do it anyway, that
seems easier to get right than passing around URLs and public keys.
- they did a Google search and yours came up first. In that case I'm
presuming the extrepo id for your repo would show up on whichever page
gets returned telling them your repo is the best. If it turns out to
be fraud (your name on someone else's key, unreliable URL), then I
think you just do the same thing as if someone wrote a webpage saying
"Here's David's awesome apt repo" with a key you don't own and a URL
you don't control.
> So you are not linking keys to URLs, which means if I can man-in-the-
> middle the users connection to extrepos.d.o I will instead of returning
> the signed key for repo A, return the signed key for my bad repo B and
> "we are fine"?
Every communication from extrepos.d.n to a user is signed by the
well-known extrepos key. You can MITM them, but only to do replays. If
you send the wrong repo, the client can see that and error out ("what's
example-123abc's details?" "foobar-555555 is ..." "err, great, but
what's example-123abc?")
> I am gonna guess your answer is the second part of the response which
> carries the sources template and which key it is supposed to be signed
> with. Here you have it, extrepo is certifying which key belongs to which
> URL, which is what SSL CAs try.
SSL CA's let you lookup a key given a URL. They assume you trust the CA
to know who owns a URL, because otherwise they could associate someone
else's key with a URL.
extrepos lets you lookup a key and URL given an arbitrarily assigned name.
It assumes you trust extrepos not to give different key/URL combos to the
same name, because otherwise someone could take over a repo. It assumes
you've got some way to establish trust in a name after it's been assigned.
They're different models.
> > I think it'd be better to maintain the extrepos keys via a script than a
> > single deb -- for one, a deb would have to be updated every time a new
> > extrepo gets created, and in any event, the user has to run some sort
> > of script to activate an extrepo anyway.
> I was thinking every repository has its own -archive-keyring package
> like it is now and the extrepo script does install this package rather
> than go of by itself and download stuff directly from the internet
> because this is hard™ to do right without running into all kinds of
> interesting cornercases like replay attacks as the problems do not end
> by just signing everything…
Downloading and installing a deb directly from the Internet is
already hard. If you put the deb in the external repo, then you have
a bootstrapping problem: you want to install from the external repo in
order to get the info you need to safely install from the external repo.
You could have extrepos just be a repo full of archive keyring debs
for each extrepo; but then everyone using extrepos is watching an
extrepos-Packages file that updates every time any extrepo gets added,
removed or changed, which seems like an unnecessary amount of churn to me.
> > > Maybe I am just pessimistic, but I kinda doubt this would change
> > > anything for this class as you usually have to do the 'curl|sh' and
> > > similar dance because there is no debian repository [...]
> > Maybe. But at the moment, even if there /were/ a debian repository,
> > "curl|sh" would be easier than going through the hoops to add the repo
> > to your system, and it's pretty hard to verify that you're not being
> > mitm'ed ("how do I know the key I've got is actually the one you wanted
> > me to add?").
> How do I know that whoever told me to add it was you?
I don't know; how do you know who I am?
What's the scenario here?
* Someone told me to add a repo.
* They convinced me it was a good idea.
* But why should I trust them?
If you don't trust them, how did they convince you? If they convinced
you already, why don't you trust them?
> I can trust that
> the data coming from extrepo is legit, but I currently can't trust it to
> give me the data I expected as valid data for repo A is just as valid as
> valid data for repo B and I have no secure way of deciding if A or B is
> the right one for me.
extrepo doesn't exist, so no, currently you can't trust it to give
you anything.
I don't know what you would "expect as valid data for repo A" -- the
model I'm describing just maps "repo A" to "url A, key A". If you already
know url A and key A, you don't need extrepo. If "repo B" also maps to
"url A, key A" then it doesn't matter which you choose. If "repo B"
maps to a different url and key, then you have to figure out whether
Alice's repo or Bob's repo is more interesting. But "interesting" could
go either way, so you'll need to actually do research to figure that out.
And no, if Alice and Bob are strangers on the Internet, there's no secure
way to know that they're not trying to hax0r your systemz. Even if one
of them were trying to do that, and everyone concerned knew this for
a fact, for some people that might be the more "interesting" choice,
and the repo they want to access.
> > > – and not few people
> > > are on the 'creating one is too much work' camp which is why I mentioned
> > > signed debs in my last response as I think is a little more realistic to
> > > replace them… in like 1 of 100 cases as the rest is too "cool and hipp"
> > > to worry about "legacy distros" now that everything can and should be
> > > done in the cloud™ where security isn't a problem…
> > Yeah, I don't disagree. I'd like to have an answer for the people who
> > *do* care about security and legacy distros, though. At the moment, I
> > don't have one other than "become a DD or DM, and get the package into
> > Debian proper".
> What makes this process so hard is that there is a proper trustpath in
> place.
No, there's not. For example:
http://nginx.org/en/linux_packages.html
For Debian/Ubuntu, in order to authenticate the nginx repository
signature and to eliminate warnings about missing PGP key during
installation of the nginx package, it is necessary to add the key
used to sign the nginx packages and repository to the apt program
keyring. Please download <this key> from our web site, and add it to
the apt program keyring with the following command:
sudo apt-key add nginx_signing.key
"this key" links to http://nginx.org/keys/nginx_signing.key, which
is signed by 7ADB39A8, 2C172083, and A524C53E. Seems like 4-6 step
paths between your key or mine to those keys. That's further than I'm
comfortable with. The links aren't even https.
What are you imaginging is the secure trust path that already exists?
(I found that by searching for "apt-key deb" on google, and following
the first link to an external repo that didn't look Ubuntu specific)
> > > No it isn't fine to have e.g
> > > deb http://httpredir.debian.org/debian sid main
> > > deb http://httpredir.debian.org/debian sid main contrib
> > > If you drop the 'main' from the second (or just the complete first) line
> > > everything is fine.
> > It seems fine even with the dupe to me? With:
> > deb http://http.debian.net/debian/ testing main contrib non-free
> > deb http://http.debian.net/debian/ testing main
> > I just get:
> > W: Duplicate sources.list entry http://http.debian.net/debian/ testing/main amd64 Packages (/var/lib/apt/lists/http.debian.net_debian_dists_testing_main_binary-amd64_Packages)
> Sure, if you not consider warnings from your package manager a problem,
> then yes, this is totally fine… with the same reasoning we could ignore
> security alltogether as this is just a warning, too, through.
Huh? apt showing a warning doesn't introduce a security problem. Ignoring
security altogether does.
"Oh my, introducing a new repo that duplicates an existing repo gives
me a warning that I have duplicated repos!!1!" just doesn't seem like
a compelling complaint to me.
Cheers,
aj
Reply to: