Apturl (security) issues and inclusion in Gutsy

Wouter Stomp wouterstomp at gmail.com
Tue Sep 25 13:22:38 UTC 2007


On 9/18/07, Alexander Sack <asac at jwsdot.com> wrote:
> On Mon, Sep 17, 2007 at 10:33:15PM +0200, Wouter Stomp wrote:
> > 1. It's possible to run arbitrary scripts in the preinst/postrm phase
> > of dpkg installation or the installed program itself could be
> > malicious. By allowing the repository to be specified the deb can come
> > from anywhere. So, you've basically got just a yes/no dialog stopping
> > arbitrary code execution. (Not far from UAC and ActiveX in windows.)
> >
>
> This is a feature of deb packages in general. ATM, you can provide
> .deb links that will run gdebi by default. The difference of apturl is
> that it allows you to ship dependencies of your provided packages as
> well.

When clicking on a .deb link, the user is given the choice between
downloading the file or opening it with an application of the user's
choice. Gdebi is only opened when the user chooses to do so.

>
> > 2. Repositories added through apturl could provide packages included
> > in Ubuntu but with higher version numbers with malicious code.
>
> ... this is a feature, not an issue.
>

This is not a feature, it is very dangerous.

> >
> > 3. there should be a VERY OBVIOUS visual indication of whether the
> > program is going to be installed from the official repos or some third
> > party site (right now it is not)
>
> If this is not obvious enough, we should take a look. ATM you get at
> least a warning because the 3rd party repository is not signed with a
> trusted key.
>

But once you have added the 3rd party repository, it can replace any
package without warning.

> >
> > 4. It is not well maintained. In the two months that it has been in
> > the archives, 20 bugs have been reported, none have been fixed. Only
> > one had a response and that is a bug about a spelling mistake in the
> > package description. (all together it seems to have been uploaded only
> > to enable the plugin wizard in firefox to work, after whcich it hasn't
> > had any more attention)
>
> Are there any serious bugs filed?
>

I think so yes, but it actually doesn't matter if they are serious or
not. One of the requirements for inclusion in main (let alone to be
shipped on the cd) is that upstream supports and cares for the
package. Well here clearly no one seems to care for the package.

> >
> > 5. It hasn't had a lot of testing. It wasn't mentioned in any of the
> > tribe release notes. There hasn't been a post in the dev-link forum or
> > on the mailing lists. So not many people know about it or have tested
> > it.
>
> The ffox plugin finder wizard was announced with tribe-5. I agree
> though, that we should call for more widespread testing/comments,
> especially how we can raise awareness about the security implications
> of 3rd party packages.
>

apturl itself wasn't announced anywhere

> >
> > 6. It functions for firefox only, even though solutions to enable it
> > for konqueror and opera have been provided in bug report. This makes
> > it impossible for a website to provide an "install this" link for an
> > Ubuntu package. They have to mention that it only works if you are
> > running firefox, not if you are a kubuntu user running konqueror for
> > example.
>
> I don't think that this is a valid argument. As you say, there are
> solutions for other browsers available. The fact that they haven't
> been integrated yet is not an issue of apturl.
>

But they should be integrated before shipping apturl by default,
otherwise it will reflect badly on ubuntu when a link works on ubuntu
but not on kubuntu or xubuntu for example because they use a different
browser.

> >
> > 7. There is currently no way for a website to know whether apt urls
> > will work on the users operating system. If a website provides an apt
> > install link it will be broken for feisty and earlier ubuntu versions
> > or other linux distributions,
>
> How is this different from providing links to .deb packages? Users
> unaware about architectures et al are not really capable to
> understand comments next to the link either. If they are, you can do
> the same for apturl links.
>

The users don't need to be aware of architectures or anything. But
there shouldn't be links to install programs on websites when they
don't work. The links should be hidden/removed when they won't work
anyway.

> >
> > 8. making people enter their sudo password in a popup you got from
> > clicking on a link on an arbitary website is definitely not secure.
>
> I see the point of this. We should investigate how we can make the
> installer more spoof-proof. IIRC, it shades the application that
> started the installer atm, which is a good start and probably hard to
> spoof with just HTML mechanisms. Maybe we can add more
> prominent/graphical hints that its now the ubuntu install wizard
> processing your request?
>

It should be made a lot harder. Currently it is very easy to spoof.
You know that effect that some pages have when an image pops up and
the website itself goes gray? Use that and add a popup asking for the
users password and the majority of users won't notice the difference.

> >
> > 9. apturl in its current version doesn't show the package description
> > so people don't have a clue about what they are about to install other
> > than the information provided on the website
>
> The package description always relies on what the package author
> provides. Either you trust the package provider or you don't.
>
> However, I agree that its worth a wishlist bug to show the package
> description in the package install confirmation dialog.
>

Which was filed a while ago.

Cheers,

Wouter




More information about the Ubuntu-devel-discuss mailing list