OSDev.org

Posted: **Mon Oct 12, 2015 6:55 am**

Hi all,

A combination of ranting and warning all you guys... Buy the guys over at Qemu really show to care about their product...
The following code is found in gdbstub.c:

Code: Select all

    case 'm':
        addr = strtoull(p, (char **)&p, 16);
        if (*p == ',')
            p++;
        len = strtoull(p, NULL, 16);
        if (target_memory_rw_debug(s->g_cpu, addr, mem_buf, len, false) != 0) {
            put_packet (s, "E14");
        } else {
            memtohex(buf, mem_buf, len);
            put_packet(s, buf);
        }
        break;

p is a string sent through the gdb socket, mem_buf here is fixed at 4096 bytes, and target_memory_rw_debug reads into that buffer "len" bytes, even though that may exceed these 4096 bytes. A trivial buffer overflow, trivial to exploit, should you ever be connected to a gdbstub.
Doesn't sound too bad, though, does it? I mean, it's only a gdbstub, you should only have access to it yourself. Except, unless you specifically block it in your firewall, you don't. They're friendly enough to let the socket bind to a hard-coded address of 0.0.0.0, thank you very much! So, unless you block it with a firewall, anyone who manages to connect at the right time is given the permission of the user running Qemu.

Now, simple fix, right? Except, after 4.5 months, I finally got a reply saying the "upstream Qemu folks" do not consider gdbstub vulnerabilities security relevant. Seriously. 4.5 months. I could've written a fix (albeit maybe not the best, but definitely not worse than now) in about 5 minutes.

I don't get that they refuse to treat a security vulnerability as such. Perhaps it's unlikely to get exploited, but there are certainly attack scenario's. Plenty of people at my uni knew I'm working on an OS, running it with Qemu, and continuously trying to connect to the proper port of my IP would definitely at some point win the race to my own connect (until I blocked it, of course).
So, anyone else running gdbstub without a firewall?

Posted: **Mon Oct 12, 2015 4:17 pm**

Don't you run a firewall? Surely you will configure it not to let traffic in on any port unless you specifically enable it. That seems to be the default for the firewalls in most OSs. I suspect that the average hobby OS that runs networking is more of a security risk on its own.

I see what you're saying, but it's not going to stop me using qemu with gdb.

Posted: **Tue Oct 13, 2015 2:27 am**

Posted a fix, feel free to review: https://lists.gnu.org/archive/html/qemu ... 02892.html

First time in a while that I'm sending a patch to a subsystem without a maintainer, so we'll see how quickly it goes, but I'm sure I'll get this in before 2.5.

Posted: **Tue Oct 13, 2015 7:57 am**

Funny enough, they e-mailed me a patch a couple of hours after mailing they had decided it wasn't considered a security issue (only after I posted this). So guess all's well, now.

I usually run a firewall, but I'd rather make sure there are no strange ports open than to disallow incoming traffic. For ports that shouldn't be open, they could simply be bound to 127.0.0.1, which I always do (except Qemu doesn't allow this for gdbstub).
Also, exploiting a hobby OS wouldn't give the attacker access to run anything on the machine running it, without a vulnerability like this one.

OSDev.org

Qemu gdb stub security

Qemu gdb stub security

Re: Qemu gdb stub security

Re: Qemu gdb stub security

Re: Qemu gdb stub security