Modify

Opened 5 years ago

Last modified 18 months ago

#13346 reopened defect

OpenWRT downloads susceptible to MITM attacks?

Reported by: openwrt-devel@… Owned by:
Priority: highest Milestone:
Component: website Version:
Keywords: MD5 SSL HTTPS MITM Cc:

Description

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.

[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

Attachments (0)

Change History (18)

comment:1 Changed 5 years ago by gz

+1
we can not forget the position of our openwrt boxes in our networks.
and openwrt.org is the perfect single-position-to-rule-them-all for the bad guys..

comment:2 Changed 4 years ago by anonymous

+1
Would be great if this could be made this year

comment:3 Changed 4 years ago by anonymous

True that md5 is susceptible to collisions, but to replace the whole image with something issue is near impossible. So I don't really see the issue with the md5 verification on the images to be honest.

comment:4 Changed 4 years ago by anonymous

The Flame malware used a MD5 collision attack
https://blogs.technet.com/b/srd/archive/2012/06/06/more-information-about-the-digital-certificates-used-to-sign-the-flame-malware.aspx?Redirected=true

"MD5 considered harmful today - Creating a rogue CA certificate"
http://www.win.tue.nl/hashclash/rogue-ca/

"
We announce two different Win32 executable files with different functionality but identical MD5 hash values. This shows that trust in MD5 as a tool for verifying software integrity, and as a hash function used in code signing, has become questionable.
"
http://www.win.tue.nl/hashclash/SoftIntCodeSign/

comment:5 Changed 4 years ago by bleeter

tl;dr - Some of the serious brains at the IETF think the Internet is probably broken beyond repair and needs re-engineering. There's no way for a reasonably well informed person to conclude otherwise. An inability to fully trust initial downloads creates a dangerous false sense of security of any subsequent updates.

Detail:
There are some problems even with https downloads, as described (albeit for another distro, but the bug entry has some good discussion in it that should get a reader thinking about how to get bootloaders and the like to trust keys/certificates as well as revocations etc. ) [1] Note it's 'oldest-bug-evar' alias and report date of 1999. Can't recall if it's mentioned there, but one way to alleviate that is to use some sort of signed BIOS system, effectively how MS use UEFI. The problems of Open Source on UEFI is well documented, I shan't cite here suffice to say there's a very large chicken and egg problem.

I believe if we, as the online commmunity with an interest in this area, consider how we can trust boot loaders to correctly handle Keys and Certificates, along with OpenPGP KeyID problems as described [2] and I do not think it is clear how 'ultra-paranoid' or even 'reasonably paranoid' end users can currently verify how they can relatively easily initially 'trust' upstream anything these days without 'positive biometric feedback indicators'.

Finally, as an aside, given it's been shown that certain Government agencies are capable of intercepting WiFi signals over 10 kilometers away with 'NIGHTSTAND' technology[3]

I believe these sorts of issues are precisely the sort of things that the IETF are looking to address in their 'perpass' discussion[4] of which there has been much debate[5]

Those still reading and with a interest of where the online community may need to go in the future, could do far worse than read Phillip Hallam-Baker's draft about a 'PRISM Proof email' system[6] in particularly his points raised about 'Policy, Audit and Transparency'.

I think the best the paranoid can hope for is vetting and building code locally and hope their build machines and production systems haven't been physically intercepted at some stage.

If vendors close tickets as this with a 'WONTFIX' or even 'NOTABUG', I can understand, however I'd like to think vendors will leave such tickets open so that if a serious proposed resolution is found in the future the existing problems can be easily checked off.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=998
[2] http://debian-administration.org/users/dkg/weblog/105
[3] http://www.engadget.com/2013/12/30/nsa-can-hack-wifi-devices-from-eight-miles-away/
[4] https://www.ietf.org/mailman/listinfo/perpass
[5] http://policyreview.info/articles/news/technical-community-debates-over-taking-back-internet/215
[6] https://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt

comment:6 Changed 4 years ago by Catalin Patulea <cronos586@…>

This issue is moot for those users of openwrt, such as myself, who build their own images.

comment:7 Changed 4 years ago by Catalin Patulea <cronos586@…>

This issue is moot for those users of openwrt, such as myself, who build their own images.

comment:8 Changed 4 years ago by bleeter

Someone asked me earlier today about how a 'self built' approach alleviates the chicken and egg problem of the compiler[1]

At minimum, I'd suggest maybe it'd be a better usage of infrastructure/development time for OpenWRT to consider reproducible/deterministic binaries[2][3] or am I showing my ignorance of current practice of OpenWRT?

[1] http://cm.bell-labs.com/who/ken/trust.html
[2] https://wiki.debian.org/ReproducibleBuilds
[3] https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise

comment:9 Changed 4 years ago by kaloz

  • Resolution set to fixed
  • Status changed from new to closed

comment:10 Changed 4 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

Where have this been fixed? The recent trunk snapshots still only have a list with md5sums in the directory. None SHA checksums. Also its still possible to download via http and not only via https. When an simple user enter openwrt.org and then go to downloads, he get by default an http connection and also download via http. Best here is to disable completely non-secure connections.

The normal openwrt. org is vulnerable to the OpenSSL CCS vulnerability (CVE-2014-0224). It also have still RC4 encryption enabled.

https://www.ssllabs.com/ssltest/analyze.html?d=openwrt.org

Also the dev.openwrt.org server is vulnerable to the OpenSSL CCS vulnerability (CVE-2014-0224). The server is running on an old nginx.

https://www.ssllabs.com/ssltest/analyze.html?d=dev.openwrt.org

comment:11 follow-up: Changed 4 years ago by anonymous

As far as I know the downloadable images are just meant for testing. (Didn't nbd say that in his CCC talk?) If you are serious about OpenWRT you compile your own image.

comment:12 Changed 4 years ago by anonymous

It is not possible for a user to listen to every CCC-talk and hope, that there are some informations about any software the user is thinking about to use. What kind of usability should this be? Maybe the user also just dont understand the english language. Luci is translated into many languages and uses the language that is been set in the user-agent of the browser.
It is also understandable, that the best way is to compile the own images. This is not neccecery for normal user who just want to add in 10minutes (from never used to working on his router) additional functionality and security.

The main reason is: kaloz told it is fixed. And thats wrong! MITM is still possible. Also SHA is not been used like told in first post.

So please fix this bugreport. The homepages have security issues, MD5 is been used where it should not be used any more, RC4 is turned on on some servers, and so on.

comment:13 in reply to: ↑ 11 Changed 4 years ago by anonymous

Replying to anonymous:

As far as I know the downloadable images are just meant for testing. (Didn't nbd say that in his CCC talk?) If you are serious about OpenWRT you compile your own image.

They may be meant that way but most people don't know how to compile their own images and the downloadable ones are the *only* ones they use.

comment:14 Changed 3 years ago by anonymous

Quick check:
openwrt.org seems to get updated from time to time. SSL3 is disabled - thanks! RC4 is still enabled.

dev.openwrt.org - Its vulnerable to the POODLE attack for a long time! Signatures are old and insecure. No one seems update the server. The Server is been managed by the developer Mirko Vogt on his own domain ( dev.openwrt.nanl.de ). A bit ironical is that he has updated the OpenSSL version in OpenWrt in 04/2014 /changeset/40423.html

Please put dev.openwrt.org on the main server that seems to be managed much better.

comment:15 Changed 3 years ago by anonymous

Quick check:

openwrt.org is vulnerable AND exploitable to CVE-2014-0224 !

dev.openwrt.org uses still old and insecure signature. POODLE is not possible any more because SSL3 got finaly disabled.

comment:16 Changed 3 years ago by anonymous

Might I suggest that openwrt also look into DNSSEC and DANE.

comment:17 Changed 3 years ago by anonymous

+1, please add shasums lists of your image downloads, and if possible sign them with a gpg key so the releases can be authenticated.

comment:18 Changed 2 years ago by J1mbo

Just to mention, OpenWRT devices can't wget via https with stock builds currently.

Add Comment

Modify Ticket

Action
as reopened .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.