Re: [LEDE-DEV] OPKG Encryption

2018-04-17 Thread Daniel Golle
Hi Jaap,


On Tue, Apr 17, 2018 at 10:03:10AM +0200, Jaap Buurman wrote:
> Hello all,
> 
> Today I discovered that pulling packages from the feeds is done over
> http by default instead of https. I understand it is always going to
> be a trade-off between space requirements and features/security.
> However, pulling in packages over an unencrypted connection will allow
> for easy manipulation of the package's contents via a MITM attack. For
> a router that is going to run these packages, that stands between all
> your devices and the big bad internet that is an unacceptable
> trade-off in my opinion.

You haven't looked closely enough.
OpenWrt uses it's own signature verification tool 'usign' to make
sure the package lists are signed by a trusted key (found in
/etc/opkg/keys). The lists contains hashes for each package, so
it's integrity can be verified based on public keys shipped with
the build at a very low overhead (usign is by magnitudes smaller
than a full TLS stack plus CA certificates).


> 
> The fix itself is quite easy and involves changing the lines in
> /etc/opkg/distfeeds.conf to https versions. Additionally, a package
> that can download over https such as wget + ca-certicates is needed.
> However, as you might already see, to fix this vulnerability you need
> to use the vulnerable component to install these packages. Or you need
> to pull in the packages via your computer, ssh it over to your router
> and install it manually. Or you need to compile these packages in.

Even if you wanted to use TLS, you'd only need to install
one of libustream-{mbedtls,openssl,wolfssl} and ca-certificates,
no need to swap all of wget (ie. uclient-fetch) with the
original bloat-version of the tool. Yet, that'd cost several
hundred kilobytes which we simply don't have on small devices.

> 
> For the majority of the people they will not even be aware of this
> vulnerability, let alone know how to fix this in a safe way. I'd like
> to discuss whether it would be a good idea to make downloading over
> https via opkg default by changing the distfeed file and including the
> required packages. We might even decide to only do this on targets
> that are not starved for flash storage. Any opinions regarding this
> matter?

Please take a look at usign and how we do verify package downloads,
if you feel anything there allows for MitM or other types of
security problems, please get back to us.



Cheers


Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] OPKG Encryption

2018-04-17 Thread Jaap Buurman
Dear Sven,

I wasn't aware of signature checking and hence I agree with yours and
Jo-Philipp's sentiment that this would be a bad idea. Please disregard
my suggestion. Thank you very much for teaching me about the signature
verification system.

Yours sincerely,

Jaap Buurman

On Tue, Apr 17, 2018 at 10:27 AM, Sven Eckelmann
 wrote:
> On Dienstag, 17. April 2018 10:03:10 CEST Jaap Buurman wrote:
>> Hello all,
>>
>> Today I discovered that pulling packages from the feeds is done over
>> http by default instead of https. I understand it is always going to
>> be a trade-off between space requirements and features/security.
>> However, pulling in packages over an unencrypted connection will allow
>> for easy manipulation of the package's contents via a MITM attack. For
>> a router that is going to run these packages, that stands between all
>> your devices and the big bad internet that is an unacceptable
>> trade-off in my opinion.
> [...]
>
> Are you aware of the Packages signature [1] and the sha256sums in the Packages
> file? opkg is checking the signature [3] when the Packages file is downloaded.
> The sha256sum is checked after the package was downloaded and before it was
> installed [4]
>
> Kind regards,
> Sven
>
>
> [1] 
> https://downloads.openwrt.org/releases/17.01.4/targets/ar71xx/generic/packages/Packages.sig
> [2] 
> https://downloads.openwrt.org/releases/17.01.4/targets/ar71xx/generic/packages/Packages
> [3] 
> https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/opkg_cmd.c;h=c823df8b6006bffa2516443fab3718cd112ae3b3;hb=3b417b9f41b4ceb5912d82f867dd5534e5675b5c#l170
> [4] 
> https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/opkg_install.c;h=e6f8a1b6276ede518a5c59b2f9347f1de8e5dd7a;hb=3b417b9f41b4ceb5912d82f867dd5534e5675b5c#l1386

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] OPKG Encryption

2018-04-17 Thread Sven Eckelmann
On Dienstag, 17. April 2018 10:03:10 CEST Jaap Buurman wrote:
> Hello all,
> 
> Today I discovered that pulling packages from the feeds is done over
> http by default instead of https. I understand it is always going to
> be a trade-off between space requirements and features/security.
> However, pulling in packages over an unencrypted connection will allow
> for easy manipulation of the package's contents via a MITM attack. For
> a router that is going to run these packages, that stands between all
> your devices and the big bad internet that is an unacceptable
> trade-off in my opinion.
[...]

Are you aware of the Packages signature [1] and the sha256sums in the Packages 
file? opkg is checking the signature [3] when the Packages file is downloaded. 
The sha256sum is checked after the package was downloaded and before it was 
installed [4]

Kind regards,
Sven


[1] 
https://downloads.openwrt.org/releases/17.01.4/targets/ar71xx/generic/packages/Packages.sig
[2] 
https://downloads.openwrt.org/releases/17.01.4/targets/ar71xx/generic/packages/Packages
[3] 
https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/opkg_cmd.c;h=c823df8b6006bffa2516443fab3718cd112ae3b3;hb=3b417b9f41b4ceb5912d82f867dd5534e5675b5c#l170
[4] 
https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/opkg_install.c;h=e6f8a1b6276ede518a5c59b2f9347f1de8e5dd7a;hb=3b417b9f41b4ceb5912d82f867dd5534e5675b5c#l1386

signature.asc
Description: This is a digitally signed message part.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] OPKG Encryption

2018-04-17 Thread Jo-Philipp Wich
Hello,

> Today I discovered that pulling packages from the feeds is done over 
> http by default instead of https. I understand it is always going to 
> be a trade-off between space requirements and features/security. 
> However, pulling in packages over an unencrypted connection will
> allow for easy manipulation of the package's contents via a MITM
> attack.

the package integrity is verified using SHA256 check sums, the checksum
file (the package index) integrity itself is verified using ed25519
based signature verification using pre-shipped public keys embedded into
the firmware images.

In order to perform a MITM, you'd need to either forge the Package index
in transit without breaking the signature verification or manage to
produce an SHA256 collision with arbitrary contents.

Opkg, by default, refuses to use downloaded package indexes that cannot
be verified.

> For a router that is going to run these packages, that stands between
> all your devices and the big bad internet that is an unacceptable 
> trade-off in my opinion.

Hence the signature based integrity verification.

> The fix itself is quite easy and involves changing the lines in 
> /etc/opkg/distfeeds.conf to https versions. Additionally, a package 
> that can download over https such as wget + ca-certicates is needed.

To match the security of the current signature system you would also
need to disallow all server certs except the one actually used by
*.openwrt.org / *.lede-project.org.

As history has shown, many pre-trusted CAs tend to have questionable
security practices.

> However, as you might already see, to fix this vulnerability you
> need to use the vulnerable component to install these packages. Or
> you need to pull in the packages via your computer, ssh it over to
> your router and install it manually. Or you need to compile these
> packages in.

Or use the existing signature verification.

> For the majority of the people they will not even be aware of this 
> vulnerability, let alone know how to fix this in a safe way. I'd
> like to discuss whether it would be a good idea to make downloading
> over https via opkg default by changing the distfeed file and
> including the required packages.

Given that the download integrity already is secured using checksums +
signed checksum files and that a "trust any HTTPS" model would actually
lower the security while requiring considerably more space, I strongly
object.

> We might even decide to only do this on targets that are not starved
> for flash storage. Any opinions regarding this matter?

Which would lead to even more confusion and a false sense of security.


~ Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] OPKG Encryption

2018-04-17 Thread Jaap Buurman
Dear Alberto Bursi,

I did not know about signature verification. I agree that there are no
secrets to hide and hence signature verification should be sufficient
to avoid tampering. Thank you very much for your reassurance.

Yours sincerely,

Jaap Buurman

On Tue, Apr 17, 2018 at 10:13 AM, Alberto Bursi
 wrote:
>
>
> On 17/04/2018 10:03, Jaap Buurman wrote:
>>
>> Hello all,
>>
>> Today I discovered that pulling packages from the feeds is done over
>> http by default instead of https.
>
>
> Just like many other distros (like say Debian that provides either http or
> ftp mirrors) the packages themselves are signed and checked by opkg on
> installation, so any MITM tampering will be detected and the package will
> not be installed. There is no need to send packages over https as there are
> no secrets being sent over, signatures are enough if you just need to avoid
> tampering and MITM.
> See wiki for details
>
> https://openwrt.org/docs/guide-user/security/security-features
>
> https://openwrt.org/docs/guide-user/security/release_signatures
>
> -Alberto

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev