1. 10

  2. 4

    Looks like they’ve rounded up a bunch of unrelated malloc-related bugs in various embedded libraries, wrapped a bow around them, and given the bundle a catchy name. Good on them for finding these, but it kind of feels like there’s some gratuitous PR going on.

    FYI, this reminds me I just read that C++20 adds some range-checked arithmetic functions, albeit as functions in the standard library, not built-in operators as in Swift or Rust.

    1. 2

      I was disappointed by the name. If I, as an embedded developer, and a user of a vulnerable codebase, am any indication:

      Target audience: BadAlloc? That’s a C++ thing. Fortunately, my RTOS only uses C.

      1. 2

        Couple of notes:

        If this is ongoing and not broadly patched yet, is it responsible to reveal this much detail about the vulnerabilities? (Cynical take: iot are generally insecure as hell anyway, the knowledge that these vulnerabilities exist doesn’t make much difference to an attacker.)

        Why the hell doesn’t calloc perform an overflow check? It literally has two jobs…

        (For that matter, why aren’t they showing calloc’s original source code?)

        1. 2

          IoT devices are never broadly patched. That’s… part of the business model.

          There’s little a responsible security researcher can do here.

          1. 1

            “Never” is an exaggeration. I own multiple IoT devices that receive firmware updates, such as WeMo smart outlets and Ecobee thermostats. (And my Eero router, if you count routers as IoT.)

            I’m aware of one RTOS vendor (forgotten the name) whose top selling point is its superior support for secure OTA firmware updates.

          2. 1

            Haven’t full read the article, so maybe I have missed some information.

            As far as I see there are patches available for the affected vendors and some of them already have patches for there devices. At this point there is no reason to hide the details of the vulnerabilities. There are tools for analyzing binary patches and find the bugs. So it’s quiet easy to understand the bugs and create exploits for other devices.

            On the defending side there is most of the time few or less information about the security issues. This brings problems about planing and executing an update (if available). Disable every device which is affected till it’s updated might be a good idea from a security perspective, but your management will not like it. So you have to do a risk management. Therefor more information about the bugs are better.