OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 2:10 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Qemu gdb stub security
PostPosted: Mon Oct 12, 2015 6:55 am 
Offline
Member
Member

Joined: Tue Dec 13, 2011 4:11 pm
Posts: 103
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:
    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?


Top
 Profile  
 
 Post subject: Re: Qemu gdb stub security
PostPosted: Mon Oct 12, 2015 4:17 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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.


Top
 Profile  
 
 Post subject: Re: Qemu gdb stub security
PostPosted: Tue Oct 13, 2015 2:27 am 
Offline
Member
Member

Joined: Sun Feb 01, 2009 6:11 am
Posts: 1070
Location: Germany
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)


Top
 Profile  
 
 Post subject: Re: Qemu gdb stub security
PostPosted: Tue Oct 13, 2015 7:57 am 
Offline
Member
Member

Joined: Tue Dec 13, 2011 4:11 pm
Posts: 103
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 25 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group