Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5810 > unrolled thread

Scripts that run insecurely-downloaded code

Back to article view | Back to linux.debian.security

Contents

  Scripts that run insecurely-downloaded code "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2020-05-01 21:20 +0200
    Re: Scripts that run insecurely-downloaded code Elmar Stellnberger <estellnb@elstel.org> - 2020-05-01 21:40 +0200
      Re: Scripts that run insecurely-downloaded code "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2020-05-01 22:20 +0200
        Re: Scripts that run insecurely-downloaded code Paul Wise <pabs@debian.org> - 2020-05-02 03:00 +0200
          Re: Scripts that run insecurely-downloaded code estellnb@elstel.org - 2020-05-02 18:10 +0200
        Re: Scripts that run insecurely-downloaded code Davide Prina <davide.prina@gmail.com> - 2020-05-02 10:20 +0200
          Re: Scripts that run insecurely-downloaded code "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2020-05-02 11:10 +0200
          Re: Scripts that run insecurely-downloaded code estellnb@elstel.org - 2020-05-02 18:30 +0200
            Re: Scripts that run insecurely-downloaded code Jason Fergus <leech@thefnords.org> - 2020-05-02 19:00 +0200
              Re: Scripts that run insecurely-downloaded code estellnb@elstel.org - 2020-05-02 19:30 +0200
          Re: Scripts that run insecurely-downloaded code Celejar <celejar@gmail.com> - 2020-05-03 16:40 +0200
      Re: Scripts that run insecurely-downloaded code estellnb@elstel.org - 2020-05-02 18:20 +0200
    Re: Scripts that run insecurely-downloaded code Paul Wise <pabs@debian.org> - 2020-05-02 03:20 +0200

#5810 — Scripts that run insecurely-downloaded code

Around 200 packages [0] include upstream scripts that download code via 
(non-secure) http, then run it without an integrity check.

This is obviously a security hole (network MITM => code execution), but 
not necessarily one that is opened by normal use of the package.  (E.g. 
fetch-dependencies-and-build scripts can't download anything on a Debian 
buildd, though it would still make sense to report them to upstream.)

Some instances of this (i.e. where the download origin offers it) are 
trivially improvable by replacing http with https.

How should this be dealt with?
- Mass report?
   - As BTS bugs (i.e. public) or private email?
- (imperfect) Lintian check based on [0]?
- If one is fixed, should it also be fixed in stable?  (Probably depends 
on how likely the script is to be used from the package)

Previous discussions that I can find [1-2] reached no clear conclusion, 
possibly because there were other issues involved (the trustworthiness 
of the downloads' intended origin, and whether downloaders had to be in 
contrib).

[0] codesearch (wget|curl).*http://[^ ]*/[^ 
]*\.(pl|sh|py|gz|xz|bz2|zip)($|[^a-z]) matches 368 packages, but not all 
of them are actual security problems
[1] https://lists.debian.org/debian-security/2012/12/msg00030.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449497

[toc] | [next] | [standalone]

#5811

https isn´t any more secure than http as long as you do not have a 
verifiably trustworthy server certificate that you can check for. As we 
know the certification authority system is totally broken. It is a bug 
if a build script tries to download something. It must work offline as 
well. I do not see any way than to rewrite these build scripts and pack 
all the necessary sources into the package for compiling it offline.

Am 01.05.20 um 20:54 schrieb Rebecca N. Palmer:
> Around 200 packages [0] include upstream scripts that download code via 
> (non-secure) http, then run it without an integrity check.
> 
> This is obviously a security hole (network MITM => code execution), but 
> not necessarily one that is opened by normal use of the package.  (E.g. 
> fetch-dependencies-and-build scripts can't download anything on a Debian 
> buildd, though it would still make sense to report them to upstream.)
> 
> Some instances of this (i.e. where the download origin offers it) are 
> trivially improvable by replacing http with https.
> 
> How should this be dealt with?
> - Mass report?
>    - As BTS bugs (i.e. public) or private email?
> - (imperfect) Lintian check based on [0]?
> - If one is fixed, should it also be fixed in stable?  (Probably depends 
> on how likely the script is to be used from the package)
> 
> Previous discussions that I can find [1-2] reached no clear conclusion, 
> possibly because there were other issues involved (the trustworthiness 
> of the downloads' intended origin, and whether downloaders had to be in 
> contrib).
> 
> [0] codesearch (wget|curl).*http://[^ ]*/[^ 
> ]*\.(pl|sh|py|gz|xz|bz2|zip)($|[^a-z]) matches 368 packages, but not all 
> of them are actual security problems
> [1] https://lists.debian.org/debian-security/2012/12/msg00030.html
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449497
> 

[toc] | [prev] | [next] | [standalone]

#5812

On 01/05/2020 20:31, Elmar Stellnberger wrote:
> https isn´t any more secure than http as long as you do not have a 
> verifiably trustworthy server certificate that you can check for. As we 
> know the certification authority system is totally broken.

Imperfect yes, but still better than nothing.

> It is a bug 
> if a build script tries to download something.

This is already policy (and enforced by blocking network access) for 
official Debian package builds: dependencies must be installed by the 
package manager, not the build script.
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

However, not all of these scripts are build scripts, and not all builds 
are .deb builds.

> I do not see any way than to rewrite these build scripts and pack 
> all the necessary sources into the package for compiling it offline.

If you mean vendored dependencies (embedded code copies), that's 
specifically *not* recommended, partly because these dependencies might 
need a security update.
https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

[toc] | [prev] | [next] | [standalone]

#5813

On Fri, May 1, 2020 at 8:18 PM Rebecca N. Palmer wrote:

> This is already policy (and enforced by blocking network access) for
> official Debian package builds: dependencies must be installed by the
> package manager, not the build script.

Correction: the debian.org buildds do not at this time block any
network access. The main issue is that schroot does not support it and
it has been orphaned and unmaintained for years. You might be thinking
of pbuilder, which does do this by default.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#5820

Am 02.05.2020 02:53, schrieb Paul Wise:
> On Fri, May 1, 2020 at 8:18 PM Rebecca N. Palmer wrote:
> 
>> This is already policy (and enforced by blocking network access) for
>> official Debian package builds: dependencies must be installed by the
>> package manager, not the build script.
> 
> Correction: the debian.org buildds do not at this time block any
> network access. The main issue is that schroot does not support it and
> it has been orphaned and unmaintained for years. You might be thinking
> of pbuilder, which does do this by default.

  I still remember the times when xchroot was a candidate and schroot did 
not yet exist. I still used to maintain it with features like 
Xorg-chroot and chroot as user 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721447, 
https://www.elstel.org/xchroot/). The problem about it that time was 
that it was not yet GPLv3.

[toc] | [prev] | [next] | [standalone]

#5815

On 01/05/20 22:00, Rebecca N. Palmer wrote:
> On 01/05/2020 20:31, Elmar Stellnberger wrote:
>> https isn´t any more secure than http as long as you do not have a 
>> verifiably trustworthy server certificate that you can check for. As 
>> we know the certification authority system is totally broken.
> 
> Imperfect yes, but still better than nothing.

There is another problem: implementation. Not all the software that 
implement HTTPS verify the validity of the certificate and the validity 
of all the certification chain.

For example where I work has been invalidated a certificate, but for 
mistake the new valid one was not loaded on a https site. With Debian 
and Firefox I cannot access that site (I get "the certificate is not 
valid" or something similar), but other people, that use another OS, can 
access it with internet explorer and chrome, but not with Firefox.

Ciao
Davide

-- 
Dizionari: http://linguistico.sourceforge.net/wiki
Sistema operativo: http://www.debian.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

[toc] | [prev] | [next] | [standalone]

#5816

Davide Prina wrote:
> Not all the software that implement HTTPS verify the validity of the certificate and the validity of all the certification chain.
These scripts are using wget or curl, which both say they do verify 
certificates.  If they do not do so correctly, please report this.

> For example where I work has been invalidated a certificate, but for mistake the new valid one was not loaded on a https site. With Debian and Firefox I cannot access that site (I get "the certificate is not valid" or something similar), but other people, that use another OS, can access it with internet explorer and chrome, but not with Firefox. 

Since this involved a revoked certificate, possibly 
https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol#Browser_support

[toc] | [prev] | [next] | [standalone]

#5822

Am 02.05.2020 10:14, schrieb Davide Prina:
> On 01/05/20 22:00, Rebecca N. Palmer wrote:
>> On 01/05/2020 20:31, Elmar Stellnberger wrote:
>>> https isn´t any more secure than http as long as you do not have a 
>>> verifiably trustworthy server certificate that you can check for. As 
>>> we know the certification authority system is totally broken.
>> 
>> Imperfect yes, but still better than nothing.
> 
> There is another problem: implementation. Not all the software that
> implement HTTPS verify the validity of the certificate and the
> validity of all the certification chain.
> 
> For example where I work has been invalidated a certificate, but for
> mistake the new valid one was not loaded on a https site.


What do you mean by loaded on a https site? That the web server of the 
site uses the certificate? Wasn´t there a CA for the new site?


With Debian
> and Firefox I cannot access that site (I get "the certificate is not
> valid" or something similar), but other people, that use another OS,
> can access it with internet explorer and chrome, but not with Firefox.
> 
> Ciao
> Davide

[toc] | [prev] | [next] | [standalone]

#5823

On Sat, 2020-05-02 at 18:01 +0200, estellnb@elstel.org wrote:
> 
> Am 02.05.2020 10:14, schrieb Davide Prina:
> > On 01/05/20 22:00, Rebecca N. Palmer wrote:
> > > On 01/05/2020 20:31, Elmar Stellnberger wrote:
> > > > https isn´t any more secure than http as long as you do not have a 
> > > > verifiably trustworthy server certificate that you can check for. As 
> > > > we know the certification authority system is totally broken.
> > > 
> > > Imperfect yes, but still better than nothing.
> > 
> > There is another problem: implementation. Not all the software that
> > implement HTTPS verify the validity of the certificate and the
> > validity of all the certification chain.
> > 
> > For example where I work has been invalidated a certificate, but for
> > mistake the new valid one was not loaded on a https site.
> 
> What do you mean by loaded on a https site? That the web server of the 
> site uses the certificate? Wasn´t there a CA for the new site?
> 
> 
> With Debian
> > and Firefox I cannot access that site (I get "the certificate is not
> > valid" or something similar), but other people, that use another OS,
> > can access it with internet explorer and chrome, but not with Firefox.
> > 
I've seen this before with Firefox.  Basically Firefox has disabled weaker certificates from
working, where Chrome and IE still accept ones with 128bit encryption, they do show an error (at
least in Chrome) if you dig into the SSL debug screen.  Firefox just refuses to view it.
> > Ciao
> > Davide

[toc] | [prev] | [next] | [standalone]

#5825

> I've seen this before with Firefox.  Basically Firefox has disabled
> weaker certificates from
> working, where Chrome and IE still accept ones with 128bit encryption,
> they do show an error (at
> least in Chrome) if you dig into the SSL debug screen.  Firefox just
> refuses to view it.

   Ah, I have read somewhere on the internet that AES-256 would be less 
secure than AES-128 because the AES algorithm has been designed for 
128bit.

[toc] | [prev] | [next] | [standalone]

#5827

On Sat, 2 May 2020 10:14:13 +0200
Davide Prina <davide.prina@gmail.com> wrote:

> On 01/05/20 22:00, Rebecca N. Palmer wrote:
> > On 01/05/2020 20:31, Elmar Stellnberger wrote:
> >> https isn´t any more secure than http as long as you do not have a 
> >> verifiably trustworthy server certificate that you can check for. As 
> >> we know the certification authority system is totally broken.
> > 
> > Imperfect yes, but still better than nothing.
> 
> There is another problem: implementation. Not all the software that 
> implement HTTPS verify the validity of the certificate and the validity 
> of all the certification chain.

I am not a security expert, but see my argument here with the Debian
ssmtp maintainer over whether a package that advertises TLS
functionality but fails to check the received certificate (and does not
mention this anywhere in its documentation) should be considered to have
an 'important' bug ;)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662960#51

Celejar

[toc] | [prev] | [next] | [standalone]

#5821

Am 02.05.2020 00:51, schrieb Marcus Dean Adams:
> It's better than nothing. Even if somebody were using self signed
> certificates that aren't publicly trusted, the information would still
> be encrypted in transit. Whether the other end is trustworthy is
> another issue and up to the user and package maintainers to decide,
> but it would, at the very least, make it more difficult for a third
> party to manipulate the information between the intended endpoints.

   Yes, I agree. With https you can only make man-in-the-middle when the 
connection is established with http you can hijack the connection any 
time. Besides this https is for sure the way to go when you are using (a 
possibly unencrypted) Wifi. It prevents people around you from 
interfering with your internet connection. For the normal user you can 
not hijack a wired LAN connection unless you would hack into ISP or root 
servers. In a country which can wiretap its citizens connections but 
does not afford to bribe certification authorities the system as we have 
it now is also a protection. I just thought of the average use case 
where a build server in Europe or the US is cabled via LAN.

[toc] | [prev] | [next] | [standalone]

#5814

On Fri, May 1, 2020 at 7:12 PM Rebecca N. Palmer wrote:

> Around 200 packages [0] include upstream scripts that download code via
> (non-secure) http, then run it without an integrity check.

A lot of these appear to be in documentation, dependency installation
scripts (such as in docker) or continuous integration scripts.

> How should this be dealt with?

Review each one manually. Report security issues for things that end
up in a .deb to upstream security contacts along with CVEs for each
issue that warrants the fixes. The upstream security reports should
probably get a Debian report too, as many upstreams will be
un(der)maintained. For CI, Dockerfiles, documentation issues probably
just an upstream pull request.

> - (imperfect) Lintian check based on [0]?

Probably better added to per-language static analysis tools like
ShellCheck etc. I don't think lintian is the place to do static
analysis, that should be done by upstream developers either on their
dev machines or in their CI and possibly by distro packagers when
analysing new upstream releases. check-all-the-things aims to make it
easy and useful for devs/packagers to run all the available tools.

https://github.com/collab-qa/check-all-the-things/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web