This evening I spent some time trying to see if I could inject libraries into Xorg on the fly using GDB, and clobber existing call symbols in the process. Haven't figured that one out yet, or even figured out definitively whether it's possible. What I have learned though, is that GDB: - Can run any library call or exported function available to the target program - Can load any accessible library and import its functions, if those aren't enough for some reason - Can call assembly labels for internal functions - Can tell you what parameters those functions take, even without debug info - Can switch between different threads in a multithreaded program and probably quite a lot more I haven't figured out yet. This makes me think I could use GDB (or other debuggers) as a test of sandbox security - a much better test than e.g. Metasploit, due to the degree of precision and control. Metasploit has to use exec* library calls to spawn its remote sessions so you can do stuff, but GDB can work at the level of function calls. If the program in whatever sandbox can be locally debugged, then I should be able to tell whether the sandbox is really comprehensive, as opposed to just whether it's good enough to make Metasploit trip over its feet. I'm going to try this out on a Windows VM later. In particular I'm hoping I can use GDB's thread functionality to look inside the Chrome sandbox on Windows 7, and perhaps compare it to the seccomp sandbox on the Linux version. Stay tuned (if you're interested)...
So, procedure: 1. Start Chrome 2. Go to some website 3. Run Chrome task manager, get PID of website renderer process 4. Run GDB against that The process for https://www.archlinux.org (for old times' sake ) has 12 threads. All the usual thousand-plus Win32 system and library calls seem to be available - GDI, Kernel32, all kinds of stuff. Running stuff through system() fails, that is pretty much expected... And everything else fails because there are no symbol tables because this is a public release. Right. One thing GDB seems not to be good at, is black-box debugging stuff. Okay, time to do some ASM diving. Edit: okay, register EIP seems to be a pointer to the address of the current function? I forget. I think that, if I set EIP to the address of the function I want, and then push the right things onto the stack in the right order, I may be able to invoke a syscall... So far all I've done is invoke a segfault though. Edit 2: Ah, progress! Setting the current frame to the address of ZwCreateProcess caused it to execute normally for about a second, before the thread exited. Now let's see if I can find a simpler API function, and feed it some sane parameters. Edit 3: Tried setting some temp variables; storing their addresses in EAX, EBX, and ECX, setting EIP to point at NtOpenProcess, and letting Chrome continue. Surprised to see that it neither hung nor crashed, so I guess I must have done something right. Progress? (For the record: the goal right now is to see if I can spawn Notepad or such within the security context of the Chrome sandbox. I'm betting I can't. )
I'm starting to think GDB may actually be the wrong tool for this job. A lot of its functionality seems to depend on debug symbols? I might be doing something wrong though. Maybe I should try writing my own (primitive) debugging too for the taskl. I'll get back to you all on this.
Pardon me for naive question, but your last post seems natural thing for me, I wonder you can build a debugger which don't need to depend on symbols even with ASM (or equivalent) command, and if it can be done, isn't it a vulnerability for public build program? But I'll wait for your next post as I really don't have clue for such advanced things. BTW, please explain if you don't care, So you could call ZwCreateProcess but couldn't spawn new process, and next tried to put a proper parameter on each register and put a address of NtOpenProcess on EIP, and could execute it and get a handle of whatever process? What does those mean?
@142395: all of it means that I have no clue whatsoever what I'm doing. EIP is (I thought, maybe not?) the register that stores a pointer to the current function. EAX, EBX, etc. can be used to store the first few arguments to a function, or all arguments if it's a simple function using the FASTCALL convention IIRC. One can also push arguments onto the stack, but I haven't figured out how to do that in GDB. Re a debugger that doesn't depend heavily on debug symbols - those already exist. They're called black-box debuggers; as in "this program is a black box with no hints as to the contents" - they're used by e.g. malware analysts to find out what a running program does. In fact the reverse engineering framework Radare, which I've used before (badly and in ignorance), contains such a debugger; so I won't have to try (and probably fail) at writing my own. (NB, I have a book on that - Gray Hat Python by Justin Seitz. Without that I wouldn't even know where to start.) So now I'm using Radare2, and trying to see if I can inject the right assembly instructions into Chrome to make it do something it shouldn't. ... And indeed I've gotten stuff wrong: http://www.cs.virginia.edu/~evans/cs216/guides/x86.html
So, a note: on Windows as on Linux, bitflags are defined with preprocessor macros, not constants. As such, stuff like gdb> call ExitWindowsEx(EWX_FORCE, "Windows has had enough.") will not work. Instead you have to do gdb> call ExitWindowsEx(0x04, "Windows has REALLY had enough now!") and Windows will (in this case) log you out pronto.
Thanks for kind explanation! Humm...my reference about x86 assembly says EIP stores address of "next" function to execute on the assumption branch won't be spawned. But I'm not sure. And thanks for ths info about black-box debuggers, I didn't know that. So they are basically a kind of reverse-engineering framework. Well, another naive question arose in my mind. Is all of Chrome code are obfuscated? I think Chromium is not obfuscated as it is open-source, right? If Chrome is well-obfuscated, and if I understand it correctly, complete reverse-compiling or reverse-assembling will be impossible. But since what matters for us is sandbox, Chromium will be enough, and now I begin to think, maybe you can also mess in Chromium source code, insert as many as symbols you like, then compile it?
Chrome isn't deliberately obfuscated AFAIK, but the Windows build is stripped of debug symbols to reduce its size, and probably heavily optimized as well. That doesn't really matter though, since I'm not reverse-engineering it, but rather trying to see what function calls are blocked by its sandbox...
Hi Gullible, Have you thought yet about recompiling the software you are going to test with gdb, i.e. that would be all of the software that implements the sandbox of which you would like to test security should be compiled with the -debug switch on in order to generate all of the packages debug symbols. With the sandbox's debug symbols being generated by recompiling as suggested, you may be able to get more information out of your exploration. Note: I am suggesting you setup a fake website on your own equipment (LAN) to emulate that which you want to test in order to run your tests in a confined environment. -- Tom
