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
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
xmdpwill 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 ofgeneral/package/xmdp/src/xmdp.cit gets a version string from the json reply:then:
verstris 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 overflowI included a
xmdp_version_bof.mdthat claude wrote to originally describe the bug, and it basically just restates what I said aboveImplications
it seems to me that
xmdpis 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
xmdpbinary in a script or something like that, then it would make this issue more seriousRepro steps
Claude wrote a poc for this bug and it seems to work
Steps:
./xmdp &python3 poc.py 127.0.0.1Suggested fix
Easy fix, just bound the length of the
versionstring from the udp reply to ensure it fits in the 128verstrbuffer