2

I write a pdf viewer that uses various libraries written in C. This C code is potentially easy to exploit. And there are just too many lines to check. I will have to assume that this code may contain exploitable bugs.

The thing is that the C code is quite straightforward. A stream of bytes go in at one end, and a bitmap (also a stream of bytes) comes out at the other.

Inspired by google chrome, I am thinking to create a separate process that does the decoding and page rendering. Ideally this should be executed in a process that has absolutely no rights to do anything except reading the one input stream it has, and outputting to a stream of bytes (some uncompresed bitmap) at the other end.

What I think the process should not be able to do is:

  • any disk access
  • open sockets
  • limited amount of memory use
  • access shared memory with other processes
  • load other dll's
  • ... anything else?

Is that possible? Is this described somewhere?

  • possible duplicate of [Is there a lightweight, programmable Sandbox API for the Windows platform?](http://stackoverflow.com/questions/2016731/is-there-a-lightweight-programmable-sandbox-api-for-the-windows-platform) –  Mar 08 '12 at 19:35

2 Answers2

1

If you have the source code - you may check it doesn't do the described things. Well, limiting available memory is a bit more difficult. You may however use SetProcessWorkingSetSize.

Also after you've built the executable you may check its DLL import table (by dependencies walker) to ensure it doesn't access any file/socket function.

valdo
  • 12,632
  • 2
  • 37
  • 67
  • What I am talking about is things that I don't want exploit code to be able to do. I think it is still possible to run functions from dll's visible to the process, by querying their adress at runtime. I am looking for a line of defense at the OS level. –  Nov 19 '10 at 23:04
  • You may also check the code doesn't import `LoadLibraryX` and `GetProcAddress`. Hence - the code won't probably be able to use any other socket/file function. Unless it's a really **badly** expoloited code, which may at runtime scan the mapped into memory kernel32.dll and locate the needed function in its export table. – valdo Nov 19 '10 at 23:11
1

This isn't really possible. Ultimately any potential exploit code will be running with whatever privileges this process runs with. If you run it as a standard user then you will limit the damage that could be done, but your best bet is to just fix the code as much as possible.

Luke
  • 11,211
  • 2
  • 27
  • 38
  • I agree that the exploit is only limited to the processes privileges. So the idea is to reduce those privileges to the bare minimum. –  Nov 20 '10 at 16:23
  • You could create a new group/user and use the local security policy to severely restrict it, but that seems a bit extreme for a little PDF viewer. – Luke Nov 24 '10 at 16:36