Re: Scripts that run insecurely-downloaded code
On Sat, 2 May 2020 10:14:13 +0200 Davide Prina 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
Re: Scripts that run insecurely-downloaded code
On Sat, 2020-05-02 at 18:01 +0200, estel...@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
Re: Scripts that run insecurely-downloaded code
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.
Re: Scripts that run insecurely-downloaded code
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.
Re: Scripts that run insecurely-downloaded code
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.
Re: Scripts that run insecurely-downloaded code
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
Fwd: Re: Scripts that run insecurely-downloaded code
The list seems to have lost this, as it doesn't appear at https://lists.debian.org/debian-security/2020/05/maillist.html. Forwarded Message Subject: Re: Scripts that run insecurely-downloaded code Date: Fri, 01 May 2020 22:51:05 + From: Marcus Dean Adams Reply-To: Marcus Dean Adams To: Elmar Stellnberger , Rebecca N. Palmer , debian-security@lists.debian.org 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. Since pretty much anybody can get a free SSL/TLS certificate from LetsEncrypt, even for your personal home network, for the majority of use cases there's really no reason to use unencrypted http any more. I digress, I'm going on a rant. I just wanted to state that I understand the OP's concerns. I would start by just emailing the developers/package maintainers for the project personally. I'm a firm believer with most things in life that if you have a problem, you handle them at the lowest possible level first and only escalate if necessary. -- ~~~ Marcus Dean Adams /"Civilization is the limitless multiplication/ /of unnecessary necessities."/ /-- Mark Twain/ On Fri, 2020-05-01 at 21:31 +0200, Elmar Stellnberger wrote: [deleted -- Rebecca]
Re: Scripts that run insecurely-downloaded code
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
Re: Scripts that run insecurely-downloaded code
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
Re: Scripts that run insecurely-downloaded code
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
Re: Scripts that run insecurely-downloaded code
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
Re: Scripts that run insecurely-downloaded code
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
Re: Scripts that run insecurely-downloaded code
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
