Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Bug Open Source Operating Systems Privacy

OpenWRT Code-Execution Bug Puts Millions of Devices At Risk (arstechnica.com) 60

Posted by BeauHD from the heads-up dept.
Dan Goodin writes via Ars Technica: For almost three years, OpenWRT -- the open source operating system that powers home routers and other types of embedded systems -- has been vulnerable to remote code-execution attacks because updates were delivered over an unencrypted channel and digital signature verifications are easy to bypass, a researcher said. Security researcher Guido Vranken, however, recently found that updates and installation files were delivered over unencrypted HTTPs connections, which are open to attacks that allow adversaries to completely replace legitimate updates with malicious ones. The researcher also found that it was trivial for attackers with moderate experience to bypass digital-signature checks that verify a downloaded update as the legitimate one offered by OpenWTR maintainers. The combination of those two lapses makes it possible to send a malicious update that vulnerable devices will automatically install.
[...]
The researcher said that OpenWRT maintainers have released a stopgap solution that partially mitigates the risk the bug poses. The mitigation requires new installations to be "set out from a well-formed list that would not sidestep the hash verification. However, this is not an adequate long-term solution because an attacker can simply provide an older package list that was signed by the OpenWRT maintainers." From there, attackers can use the same exploits they would use on devices that haven't received the mitigation. OpenWRT maintainers didn't immediately respond to questions asking why installation and update files are delivered over HTTP and when a longer-term fix might be available. In the meantime, OpenWRT users should install either version 18.06.7 or 19.07.1, both of which were released in February. These updates provide the stopgap mitigation.
This discussion has been archived. No new comments can be posted.

OpenWRT Code-Execution Bug Puts Millions of Devices At Risk More

OpenWRT Code-Execution Bug Puts Millions of Devices At Risk

Comments Filter:

  • The bug is in the signature verification (Score:5, Interesting)

    by Pinky's Brain ( 1158667 ) on Wednesday April 01, 2020 @05:18AM (#59896306)

    Is it just me or does the introduction of the bug look a bit suspect? The change in the source code looks strangely specific.

  • Mostly a non-issue (Score:4, Informative)

    by gweihir ( 88907 ) on Wednesday April 01, 2020 @05:36AM (#59896334)

    Intercepting connections in the open net is actually pretty hard. In a LAN, it can be easier, but once you trust your LAN, this is also pretty much a non-issue.

    Sure, this should be fixed, but "millions of devices at risk" is just amateur-level hyperbole.

    • Re:Mostly a non-issue (Score:4, Insightful)

      by Opportunist ( 166417 ) on Wednesday April 01, 2020 @06:02AM (#59896368)

      It's not that trivial. Yes, conducting a mitm isn't easy and yes, outside of being a state actor that can tell the ISP to "help" you you're most likely SOL, but the fact that updates are done via http means that DNS tampering is an issue. That still takes either a compromised DNS server the router is using (potentially its own) or a compromised DNS server at your ISP (provided you use that one instead of, say, Google's), but the danger is not such a non-issue as you try to make it.

      It might not happen to you, and most likely not to me, since we know how to secure our equipment, but how many using OpenWRT actually do know a lot about security and don't just rely on it to work as expected?

      The update being published via http is the key problem here. Why is this done in 2020? There is literally no excuse not to use https for critical traffic these days. And it's not about encryption this time but about the ability to verify the source as being genuine.

      • Well, I'm not excusing it, but there is a cost factor... on the order of about 20% extra server CPU load and a similar percentage of extra bandwidth used. There's also the cost of using commercial encryption certs and keeping them updated, so that everyone's computer already trusts yours without the user having to take extra steps and know how to. If you're a popular project serving relatively large files, these costs add up.

        • Re:Mostly a non-issue (Score:4, Insightful)

          by Opportunist ( 166417 ) on Wednesday April 01, 2020 @06:25AM (#59896416)

          Free certs can be gotten from LetsEncrypt, cost is not really an issue anymore. And since the OpenWRT-Box only has to communicate with a single server, you can even go as far as self-sign and pin it. So what's really left is CPU and bandwidth use. I can't comment on that since I honestly don't know what we're looking at here, if someone knows whether this really is an issue, please let us know.

      • It might not happen to you, and most likely not to me, since we know how to secure our equipment, but how many using OpenWRT actually do know a lot about security and don't just rely on it to work as expected?

        I would suggest that if you are using OpenWRT, then you are already much more knowledgable than someone who is using the stock router firmware.

        • It might not happen to you, and most likely not to me, since we know how to secure our equipment, but how many using OpenWRT actually do know a lot about security and don't just rely on it to work as expected?

          I would suggest that if you are using OpenWRT, then you are already much more knowledgable than someone who is using the stock router firmware.

          I would whole heartedly agree. OpenWRT does NOT work "out of the box" and if you don't have at least *some* idea of what's going on it's going to be really hard to configure. I'm not saying OpenWRT is bad, I'm just saying that it is not consumer friendly. Luci is great, but the work flows are horrible and inconsistent and many times don't cover *your* specific needs so you drop to the command line. The command line is incomprehensible for even knowledgeable network engineers and really using OpenWRT to

        • Do you need to know a thing or two about TCP or about network security to get it running?

          They are not exactly the same.

          • Re: (Score:2)

            by gweihir ( 88907 )

            To get it running well and securely, then both. Also, if you do not understand TCP/IP networking, you have no business doing network security.

      • Well, given that OpenWRT is targeted at enthusiast consumers, pretty secure on its own, and the nature of this vulnerability, I don't see much risk. You'd have to target a specific router and either break into it (so why bother tampering with updates) or alter traffic/DNS at the ISP level. Also, the way OpenWRT updates work means that you aren't usually updating individual packages, they're mostly built for specific firmware versions and don't auto-update. So packages are usually only installed after a f

      • People using openwrt TEND to be like you and me... We know how to secure our gear.

        Openwrt is NOT dd-wrt and it's NOT installed in off-the-shelf equipment. Derivatives may be, but they won't be using that update code either.

        As another poster noted... Amateur hyperbole. In the comments on ARS, one of the commenters was howling he "... wasn't going to assist a for profit company by auditing their code"... Demonstrating a clear lack of clue as to the nature of openwrt.

      • Re: (Score:2)

        by Shark ( 78448 )

        To be clear... Updates are never pushed. You pull them yourselves and never in an automatic/scheduled manner.

        This is not a case of "OMG, my device can get remotely Pwned at any time!"

        Keep in mind that the update is *accessible* via http so that routers which are typically too space-limited to have openssl/gnutls/etc. by default can download it directly but that is not the typical update route.

        Typical update route is that the user will download (via the https default) the firmware using their regular brows

        • Re: (Score:2)

          by gweihir ( 88907 )

          Thanks. Exactly my point. This is not an update automatically pulled where an attacker just has to sit on the line when the next version comes out.

  • Digital signatures shouldn't be easy to bypass. It's perfectly sensible to transfer the update image over plain http as long as the signature of the downloaded image is checked before being updated.
  • Criminal negligence. Ten years. Officer, remove the defendant.

  • Http is what Linux apt-get uses (Score:5, Informative)

    by jshipp ( 2519316 ) on Wednesday April 01, 2020 @06:46AM (#59896448) Homepage
    But, it uses proper signature verification. https://whydoesaptnotusehttps.... [whydoesapt...ehttps.com]

    • Yes, because the packets themselves are signed and you have the relevant keys to verify that signature already on your machine. That's another way to do it, but either way you need some way to verify what you got. Either you sign the connection or the content, but in either case the system already must have some kind of key available to verify the signature to be genuine, that means you either have to pre-load the system with a key to the connection (as we have in https) or the key to verify the signature o

      • " the packets themselves are signed "... WTF are you talking about?!
        Unless we're talking about IPSec, no, packets are NOT signed (even then they aren't, but that's a whole 'nother discussion). If they were, address spoofing wouldn't work... And it does quite handily.

        I suggest taking an elementary Wireshark class or even read a TCP/IP tutorial. THEN you may make comments.

    • And it never fails:

      Remote Code Execution in apt/apt-get [justi.cz]

  • IMPOSSIBLE! (Score:2, Insightful)

    by DaveV1.0 ( 203135 )
    Everyone knows these things CAN'T happen with open sources because many eyes and all that bullshit.

    • Re: (Score:1)

      by Anonymous Coward

      You do realize the article is about the "many eyes" successfully spotting and fixing a bug, right? The system is working as intended.

      • It only took *checks article*

        almost three years

        If that is working as intended then it is no better than closed source.

        • You don't know whether it's better or not, because you can't audit the closed source software's sources to look for bugs. You're just taking it on faith that they're better, without any evidence whatsoever. Do you also believe the Earth is 6,000 years old?

    • Re:IMPOSSIBLE! (Score:4, Insightful)

      by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday April 01, 2020 @08:30AM (#59896690) Homepage Journal

      I have never seen anyone claim that. What people actually claim is that more bugs/vulns are found due to many eyes, and fixed due to many hands. And they further claim that since you don't have the sources to closed source software, you can't check it yourself.

      Then people like you and the other chuckleheads who responded to your little back-patting party claim that they said open source made them completely immune as a means of discrediting their argument, and/or validating your use of closed software, making you feel smug and/or secure.

      However, vulnerabilities to closed source software frequently exist in the wild, and you're mischaracterising the argument, so neither your smugness nor your sense of security is warranted.

    • Of ESR had said "with enough eyeballs, all bugs are not exist", that would have been a silly statement indeed. Of course, that's not what he said

      He said "with enough eyeballs, all bugs are shallow - the solution will be obvious to someone".

      If you're not familiar with deep vs shallow, shallow is you look at a bug report and it's clear exactly what's wrong and how to fix it. Deep is when you are wracking your brain trying to figure it out. For example the Internet Explorer vary header bug that sat unfixed

      • Three
        fucking
        years
        It took three years to spot this bug.

        Also, I suggest you go back through the last 10 to 15 yeas of slashdot articles and say that to all the FLOSS zealots who use "with enough eyes all bugs are shallow" to mean it is easy to spot bugs.

        • How long it took for someone to spot a bug doesn't.have anything whatsoever to do with quote and the process oy describes. I'm sorry you got confused and thought it did.

          > Also, I suggest you go back through the last 10 to 15 yeas of slashdot articles and say that to all the FLOSS zealots

          I've been on Slashdot for about 15 years (this is my second account) and the only people I see thinking that are are about four people who made the same post you did. Essentially "having a lot of people who can fix bugs

    • Re: (Score:1)

      by Anonymous Coward

      Do you enjoy having intercourse with your strawman after you're done knocking it over?

  • What ? OpenWRT is Americans ? Well in that case let's give them the benefit of the doubt.

  • More fallacies (Score:2, Informative)

    by Anonymous Coward

    The encryption HTTPS provides makes it impossible for nearby attackers to tamper with data while it’s in transit.

    Why do people keep spreading this lie? Re-encrypting proxy appliances at corporations and government offices inspect and modify HTTPS traffic every day. Your company requires you to install a Provisioning Profile on your macOS/iOS/Android device to use their networks or services? Bet your ass they're reading your "secure" traffic.

  • Did they already forget about HTTP?
  • I just gave up on unverifiable firmware and got a Synology Router.. it's good enough and the firmware is from a brand name vs some group that any assholes could inject money into and buy their loyalty.

  • As long as it matters to you, and if your router has enough memory, here's how to update opkg lists using https:
    From: https://www.leowkahman.com/201... [leowkahman.com]
    "Configuring OPKG to retrieve via HTTPS
    opkg install ca-certificates
    opkg install libustream-openssl
    If you have LuCI (GUI) installed, enabling SSL is very easy. Navigate to System > Software > Distribution feeds. Replace all http:/// [http] URLs to https://./ [.]
    If you do not have LuCI, you will have to edit /etc/opkg/distfeeds.conf using your preferred editor."
    Then

  • even with a 'vulnerability' like this, i very much prefer to run openwrt compared to the trash most of these home routers have running on them.

Slashdot Top Deals

Single tasking: Just Say No.

Close