Qemu gdb stub security

All off topic discussions go here. Everything from the funny thing your cat did to your favorite tv shows. Non-programming computer questions are ok too.
Post Reply
evoex
Member
Member
Posts: 103
Joined: Tue Dec 13, 2011 4:11 pm

Qemu gdb stub security

Post by evoex »

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?
User avatar
iansjack
Member
Member
Posts: 4689
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Qemu gdb stub security

Post by iansjack »

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.
Kevin
Member
Member
Posts: 1071
Joined: Sun Feb 01, 2009 6:11 am
Location: Germany
Contact:

Re: Qemu gdb stub security

Post by Kevin »

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.
Developer of tyndur - community OS of Lowlevel (German)
evoex
Member
Member
Posts: 103
Joined: Tue Dec 13, 2011 4:11 pm

Re: Qemu gdb stub security

Post by evoex »

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.
Post Reply