Re: flashplugin-nonfree get-upstream-version.pl security concern
On Thu, 2012-12-13 at 19:55 -0500, Michael Gilbert wrote: > On Wed, Dec 12, 2012 at 11:41 PM, Jason Fergus wrote: > > On Wed, 2012-12-12 at 17:26 -0500, Michael Gilbert wrote: > >> On Wed, Dec 12, 2012 at 12:52 PM, adrelanos wrote: > >> > What is Debian policy on code execution from user websites? > >> > >> Unfortunately there is none. I've tried to gain consensus that at a > >> minimum things downloaders like this need to stay out of main, but > >> that thought hasn't really gained traction. > >> > >> The real answer is that this package is in contrib and thus not > >> security supported at all. Ultimately, for anyone even modestly > >> security-conscious adobe flash should really be avoided at all costs. > >> Alternatives include lightspark, gnash, and (most preferably) html5. > >> > >> Best wishes, > >> Mike > >> > >> > > I could be wrong on this, but I had always thought that ANY sort of > > downloader type installer (like the flashplugin-nonfree package) could > > NOT be in main. For any package to be in main, it has to have source > > code available as well as DFSG compliant. It's the same reason why > > quake2-data packages were always in contrib. While the source code for > > quake2 is GPL, the -data package would grab the pk0.pak files off of the > > CD to put them in the proper place for global Quake 2 fun. quake2-data > > was always in contrib. I was going to use qmail as an example, but I am > > guessing they changed their license recently, because previous to > > Wheezy, you always had to build it from source (and there was a > > qmail-src package). > > You would think that, but Debian policy has nothing to say. I put a > lot of energy into it, but things like getweb still remain: > http://bugs.debian.org/449497 > > These cases are actually pretty rare, which is the real reason that > there is no defined policy. Plus people tend to not like repacking > upstream due to single questionable files. > > > Anyhow, I hope that point was made clear. Contrib also does get > > security updates, but they're not maintained by the security team (if > > I'm recalling correctly. Sucks getting old). They're simply maintained > > by the package maintainer. > > Well, there's always the option for the maintainer to provide a > security update an spu, but that is so rare in contrib that I don't > recall the last time it happened. > > Without security team intervention happens in probably 95% of cases > for security issues, so there's something like a 5% of a fix going > into contrib. Maintainers tend to lose interest in the stable release > fairly quickly. > Pretty sure I've seen the flashplugin-nonfree updated for Squeeze at some point, but I could be wrong. > Best wishes, > Mike > > -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1355452450.10685.25.camel@localhost.localdomain
Re: flashplugin-nonfree get-upstream-version.pl security concern
On Wed, Dec 12, 2012 at 11:41 PM, Jason Fergus wrote: > On Wed, 2012-12-12 at 17:26 -0500, Michael Gilbert wrote: >> On Wed, Dec 12, 2012 at 12:52 PM, adrelanos wrote: >> > What is Debian policy on code execution from user websites? >> >> Unfortunately there is none. I've tried to gain consensus that at a >> minimum things downloaders like this need to stay out of main, but >> that thought hasn't really gained traction. >> >> The real answer is that this package is in contrib and thus not >> security supported at all. Ultimately, for anyone even modestly >> security-conscious adobe flash should really be avoided at all costs. >> Alternatives include lightspark, gnash, and (most preferably) html5. >> >> Best wishes, >> Mike >> >> > I could be wrong on this, but I had always thought that ANY sort of > downloader type installer (like the flashplugin-nonfree package) could > NOT be in main. For any package to be in main, it has to have source > code available as well as DFSG compliant. It's the same reason why > quake2-data packages were always in contrib. While the source code for > quake2 is GPL, the -data package would grab the pk0.pak files off of the > CD to put them in the proper place for global Quake 2 fun. quake2-data > was always in contrib. I was going to use qmail as an example, but I am > guessing they changed their license recently, because previous to > Wheezy, you always had to build it from source (and there was a > qmail-src package). You would think that, but Debian policy has nothing to say. I put a lot of energy into it, but things like getweb still remain: http://bugs.debian.org/449497 These cases are actually pretty rare, which is the real reason that there is no defined policy. Plus people tend to not like repacking upstream due to single questionable files. > Anyhow, I hope that point was made clear. Contrib also does get > security updates, but they're not maintained by the security team (if > I'm recalling correctly. Sucks getting old). They're simply maintained > by the package maintainer. Well, there's always the option for the maintainer to provide a security update an spu, but that is so rare in contrib that I don't recall the last time it happened. Without security team intervention happens in probably 95% of cases for security issues, so there's something like a 5% of a fix going into contrib. Maintainers tend to lose interest in the stable release fairly quickly. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnek8zlybcnz+ebxv-qg6ez4h92bjd8xi_xe6fuxbh...@mail.gmail.com
Re: flashplugin-nonfree get-upstream-version.pl security concern
On Thu, Dec 13, 2012 at 1:47 PM, Davide Prina wrote: > On 12/12/2012 23:26, Michael Gilbert wrote: >> Ultimately, for anyone even modestly >> security-conscious adobe flash should really be avoided at all costs. > +1 > I'm not an expert, but I think that packages like this must first ask the > users list on which you want this plugin installed and than execute scripts > only for those users as user not root with, for example, su -c USER1 > "script.sh" ... (downloading the file [with ugo+r] in /tmp/RANDOMDIR [with > ugo+x] only once). Why does the group and other need access again? Even if it's read only you are still introducing fatal security problem indirectly by promoting the usage of global read. > Also I think that these packages must alert the user that they will download > somethings from a website and ask for a confirmation to continue (I don't > know if it is already implemented). -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cam5xqnxvhdtp1qamu0gfsad8fx8rd4x+ckpteujguxu_n8r...@mail.gmail.com
Re: flashplugin-nonfree get-upstream-version.pl security concern
On 12/12/2012 23:26, Michael Gilbert wrote: Ultimately, for anyone even modestly security-conscious adobe flash should really be avoided at all costs. +1 I'm not an expert, but I think that packages like this must first ask the users list on which you want this plugin installed and than execute scripts only for those users as user not root with, for example, su -c USER1 "script.sh" ... (downloading the file [with ugo+r] in /tmp/RANDOMDIR [with ugo+x] only once). Also I think that these packages must alert the user that they will download somethings from a website and ask for a confirmation to continue (I don't know if it is already implemented). Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Fate una prova di guida ... e tenetevi la macchina!: http://linguistico.sf.net/wiki/doku.php?id=usaooo2 Non autorizzo la memorizzazione del mio indirizzo su outlook -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50ca30db.6090...@gmail.com
Re: flashplugin-nonfree get-upstream-version.pl security concern
Mike Mestnik writes: > The link($1) can't contain a ", but a few others(I.E ') should be added > to this list and use... > open INPUT, "wget --user-agent=\"$user_agent\" -qO - \"$url\" |" or die; > or > open INPUT, "wget --user-agent='$user_agent' -qO - '$url' |" or die; Using the three-or-more argument form of open is better: open INPUT, "-|", "wget", "--user-agent=$user_agent", "-qO", "-", $url or die; This avoids using the shell (unless there's only one argument, see perldoc -f open for that case). Even in this case one should make sure that $url is sane and doesn't for example start with a dash like options. It's also possible to use (for example) LWP::UserAgent here. Ansgar -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3slhpoy@eisei.43-1.org
Re: flashplugin-nonfree get-upstream-version.pl security concern
On 12/12/12 13:10, Henrik Ahlgren wrote: > On Wed, Dec 12, 2012 at 05:52:31PM +, adrelanos wrote: >> Since get-upstream-version.pl runs as root it can do anything. >> >> I don't accuse him personally for anything. But should he ever be >> compromised (forced, evil maid, etc...) it's very easy to mount a >> stealth attack. > > I would worry more about the Adobe's web site getting compromised. > The get-upstream-version.pl script fetches the link to the Flash > player from www.adobe.com and then the download page: > > open INPUT, "wget --user-agent=\"$user_agent\" -qO - $url |" or die; > > It runs wget using the shell and there is basically no validation for > what $url contains. Even if taint mode was used, this would untaint > the value no matter what it happens to contain: > > $page =~ m,Adobe Flash Player,s > or die "link to Adobe Flash Player not found on $url"; > > my $link_to_flash = $1; > > What would happen if the link happened to contain "; some nasty > command"? > The link($1) can't contain a ", but a few others(I.E ') should be added to this list and use... open INPUT, "wget --user-agent=\"$user_agent\" -qO - \"$url\" |" or die; or open INPUT, "wget --user-agent='$user_agent' -qO - '$url' |" or die; > Given Adobe's security track record with their software products, I > would not trust their web site too much. In fact, I would not like > to run that kind of script against any normal corporate web site, > especially non-https one! > Validation of retrieved content should also be the responsibility of this package. There should be signature files as part of a volatile(or whatever replaced that) package, using only files that have been signed by a DD seams like a good item to have added to Policy. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50c9f69e.3040...@mikemestnik.net
Re: flashplugin-nonfree get-upstream-version.pl security concern
On 12/12/12 12:02, Moritz Mühlenhoff wrote:> On Wed, Dec 12, 2012 at 05:52:31PM +, adrelanos wrote: >> Hi, >> >> I do not want to discuss security implications of the upstream closed >> source Adobe Flash plugin. This is about how the Flash plugin is >> downloaded and installed in Debian. >> >> /usr/sbin/update-flashplugin-nonfree downloads get-upstream-version.pl >> http://people.debian.org/~bartm/flashplugin-nonfree/get-upstream-version.pl.gz.pgp >> stores it in /tmp/xxx, runs it and deletes /tmp/xxx. > > It should at least use a non-predictable tempfile (using tempfile(1) ) > > Please file bug for that. > >> Since get-upstream-version.pl runs as root it can do anything. >> >> I don't accuse him personally for anything. But should he ever be >> compromised (forced, evil maid, etc...) it's very easy to mount a >> stealth attack. >> >> Also reviewing get-upstream-version.pl is cumbersome, you either have to >> be fast enough to catch it in /tmp/xxx or to download and decrypt it >> manually using his gpg key. >> >> So far it looks clean. But that's not best security practice? >> >> What is Debian policy on code execution from user websites? > > There are a few downloaders like this in contrib/non-free. > This is one of the better ones; after all you need to trust > every DD not to muck with your systems (postinst scripts run as root, e.g.) > Hmm, I think most users will take the meaning of this Debian package to be that it downloads content from Adobe. Users are well within sane reasoning to be surprised that it downloads content from anywhere else... and then precedes to run said content as root. Strictly speaking the content of a package should have been vetted by FTP Masters for copyright violations and the like. As contrib/non-free and specifically this package is a means to circumvent this, it should not be allowed to do so without restrictions. Specifically the copyright on this file could change at any time, exposing users to legal problems. As for Adobe, lets assume that the user has a good working relationship and/or contracts and are otherwise on the best of terms. This is where "Who" the content is coming from plays a big role. Just my thoughts. > Plus, installing Flash opens the Pandora's box anyway > This is not the issue as stated in the first paragraph, safely ignore this for the sake of a healthy discussion. Arguments along this line are just plain ugly, for both sides. > Cheers, > Moritz > > > -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50c9ec99.3070...@mikemestnik.net
