Skip to content

Minor security vulnerabilty in xmdp leading to stack bof during a scan #2293

Description

@MrStashley

poc.py

Disclaimer: I used claude to find this bug, so it may be AI slop, but I manually reviewed its output and it seems like a real bug to me. It also generated a crashing POC so I think that adds to credibility. I apologize if I missed something and it turns out it's not a real bug.

it seems like xmdp will scan for certain IP camera devices by broadcasting a UDP probe and parsing replies as json. Replies are unauthenticated at this point, so any device that hears the broadcast can respond with a reply. The reply seems to be a json string with information about the device.

in scan() on line 181 of general/package/xmdp/src/xmdp.c it gets a version string from the json reply:

    const char *version = get_json_strval(netcommon, "Version", "");

then:

   char verstr[128] = {0};
   if (strlen(version)) {
      int n_dot = 0, i = 0;
      while (*version) {
        if (*version == '.') {
          n_dot++;
          if (n_dot == 4)
            break;
        } else if (n_dot == 3) {
          verstr[i++] = *version;
        }
        version++;
      }

verstr is a static 128 byte stack buffer, and this loop will copy an unbounded amount of bytes from the udp response to this buffer as long as the version string has less than 4 . characters. So this is a stack buffer overflow

I included a xmdp_version_bof.md that claude wrote to originally describe the bug, and it basically just restates what I said above

Implications

it seems to me that xmdp is just a util binary that would have to be manually run by a user, and the vulnerability only exists on a broadcast response, so it's not super serious, but if an unsuspecting user ever does run this binary, then this vulnerability can be exploited with no auth by any device on the network.

If any other part of the firmware runs the xmdp binary in a script or something like that, then it would make this issue more serious

Repro steps

Claude wrote a poc for this bug and it seems to work

Steps:

  • Build xmdp binary from this repo
  • run ./xmdp &
  • run python3 poc.py 127.0.0.1
  • observe SIGSEGV in xmdp process

Suggested fix

Easy fix, just bound the length of the version string from the udp reply to ensure it fits in the 128 verstr buffer

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions