[OpenWrt-Devel] OpenWRT downloads susceptible to MITM attacks?

[Peter Lawler]

Hi!
(This email is a copy of a Trac ticket I've just submitted,
https://dev.openwrt.org/ticket/13346 , in an effort to encourage discussion)

Over at pidgin.im, we've recently been upgrading our distribution
systems to minimise the possibility of MITM attacks against our
downloads.[1][2] While www.openwrt.org, openwrt.org, dev.openwrt.org,
forum.openwrt.org, git.openwrt.org and lists.openwrt.org are available
on https[3], downloads.openwrt.org is not available without triggering a
browser security warning (as it's noton the listof certificate hosts).

With the release of AA-RC2, it occurred to me that OpenWRT is
susceptible to similar possible attacks. I also note that the
certificate is set to expire in about 3 months time, it would be great
to see downloads.openwrt.org added to the certificate's common names, as
well as firmware only distributed over https (ie, turn off http downloads).

Further, OpenWRT provides MD5 checksums for it's images. MD5 is known to
be not collision resistant.[4]

It is also known that it's possible to create files that have the same
MD5 value.[5][6]

To paraphrase CMU Software Engineering Institute, MD5 should no longer
be used.[7]

To paraphrase NIST, please move to SHA-2.[8]

Given the place that OpenWRT sits in people's networks, I would strongly
encourage the development team to consider moving the download system to
forcing HTTPS connections and ditching MD5 for SHA-2.

Regards,

Pete.


[1] https://developer.pidgin.im/ticket/15277
[2] http://pidgin.im/pipermail/devel/2013-April/011214.html
[3]
https://www.sslshopper.com/ssl-checker.html#hostname=downloads.openwrt.org
[4] http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf
[5] https://en.wikipedia.org/wiki/MD5#cite_note-autogenerated1-4
[6] http://www.cs.colorado.edu/~jrblack/papers/md5e-full.pdf
[7] http://www.kb.cert.org/vuls/id/836068
[8] http://csrc.nist.gov/groups/ST/hash/policy.html

[Manuel Munz]

Post by Peter Lawler
Given the place that OpenWRT sits in people's networks, I would strongly
encourage the development team to consider moving the download system to
forcing HTTPS connections and ditching MD5 for SHA-2.
Regards,
Pete.

I agree with most of what you said and think this should be done. But
not with that https should be enforced. One upgrade path for me and many
others is to wget a new image. wget in busybox does not support ssl, so
we would be forced to install the full wget + ssl libs just for this task.

Regards, soma

[Peter Lawler]

Post by Manuel Munz

Post by Peter Lawler
Given the place that OpenWRT sits in people's networks, I would strongly
encourage the development team to consider moving the download system to
forcing HTTPS connections and ditching MD5 for SHA-2.
Regards,
Pete.

I agree with most of what you said and think this should be done. But
not with that https should be enforced. One upgrade path for me and many
others is to wget a new image. wget in busybox does not support ssl, so
we would be forced to install the full wget + ssl libs just for this task.
Regards, soma

That's a very good point that, with apologies, I'd not considered at
6AM, because of (a) lack of coffee (b) the boxen I have myself ;)

I guess this sort of raises the questions whether systems that are known
to have sufficient flash should be built with wget + ssl by default, as
well as luci-ssl?

They're always the first thing I throw on and having them downloaded
over http does seem a bit self defeating.

Regards,

Pete.

[Jonathan Thibault]

Space is still kind of precious on most devices, the fact that it fits
doesn't mean that most people would want it as a default option.

I would suggest making sha-2 digests and files available through https
but leaving it to the user to make their own checks and take their own
risks in failing to do so.

Jonathan

Post by Peter Lawler

Post by Manuel Munz

Post by Peter Lawler
Given the place that OpenWRT sits in people's networks, I would strongly
encourage the development team to consider moving the download system to
forcing HTTPS connections and ditching MD5 for SHA-2.
Regards,
Pete.

I agree with most of what you said and think this should be done. But
not with that https should be enforced. One upgrade path for me and many
others is to wget a new image. wget in busybox does not support ssl, so
we would be forced to install the full wget + ssl libs just for this task.
Regards, soma

That's a very good point that, with apologies, I'd not considered at
6AM, because of (a) lack of coffee (b) the boxen I have myself ;)
I guess this sort of raises the questions whether systems that are
known to have sufficient flash should be built with wget + ssl by
default, as well as luci-ssl?
They're always the first thing I throw on and having them downloaded
over http does seem a bit self defeating.
Regards,
Pete.
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[Bastian Bittorf]

Post by Jonathan Thibault
Space is still kind of precious on most devices, the fact that it fits
doesn't mean that most people would want it as a default option.

maybe it is possible to hackup the busybox-wget with polarssl?

bye, bastian

[Nick Podolak]

To the original poster's point, it would be nice if at the very least the
site's SSL certificate, which is due for renewal shortly, supported the
downloads.openwrt.org URL.