Software systems rarely do; the larger the piece of software, the more likely bugs are to creep in. If one of those bugs happens to let you run arbitrary code, that's a problem.
To be clear, this arbitrary code is typically actually a specially crafted piece of input into the program. For example, let's assume there's a bug in the
.image renderer (a file type we've made up for the purposes) where I read data that should look like this:
FF 00 99 00 00 00
For reasons unknown, I've chosen to do crazy things like storing this RGB code in strings and am assuming string terminates with
00 and there's actually only one character. I don't know, maybe I'm anticipating bazillion colour screens. This may be a poor example. It's late. Bear with me. Anyway, let's assume I just use standard string functions in by renderer to copy that information out of the file. Now, if I send a valid file, great. However as an attacker, I could send a file that looks like this:
FF 00 99 11 11 11 11 11 11 <lots of 11s> 11 11 <some code> 00
How could I send that file? Easy. Include it in the html of the web page with bog standard
img tags. The browser will then open/render the image (as it does with jpgs, pngs etc) and my broken dodgy code happily executes that buffer overflow. I might even be sneaky and
display: none; it via css, but only if the browser still processes it.
At this point, those instructions in
<some code> get executed, which allows me to do whatever I need to. Typically, this downloads an executable of some sort and runs it, which means the exploit only needs to be small and I can download something meatier if the exploit worked.
From there, the "payload" can begin attempting to elevate privileges and installing backdoors. You already have a good answer on what a backdoor could do and how it might work.
I've chosen to make up an image file with a very simple mistake nobody should make; however, in the real world there are all sorts of media which have very complex results:
- PNG/JPG/GIF - I'd expect a bug in these to be rare, but I believe it has happened (not sure if it caused a remote execution vulnerability though).
- More complex movie formats, e.g. MP4 etc.
Now, two scenarios are slightly more complicated:
- Java applets allow arbitrary code execution - in Java. There are three possible outcomes here:
- You can avoid the signing dialog display via some mechanism and so load your class without user interaction, giving you the ability to download/exec code.
- You can find a bug in the classloader or jar parser that you can exploit.
- There is some bug in the Java language and/or runtime you can convince the user to use.
- ActiveX controls: these are, effectively, DLLs or EXEs with "special magic". It's Open Season with one of these; the only barrier here is avoiding (by getting a valid signature, social engineering or a bug) the authenticode (code signing) screen you (should) get before running one.
Baaasically, the browser environment is incredibly complicated and there are a lot of moving parts that must all read untrusted input and correctly handle it.
Now, that little comment of Rory's:
Point 5 is dramatically understating what the attacker can do.
Massively, really, megarly (that's a word now) understating what the attacker can do. Since a remote access trojan has full control of your PC, a few things an attacker may do:
- Install further code, on demand, to carry out or co-ordinate attacks on other systems. This is commonly referred to as being part of a botnet.
- Harvest any interesting-looking information from the current system.
- Go around damaging things. Quite rare these days.
- Drop payloads onto any media/medium likely to enable the attacker to an exploit another system, e.g. infecting all USB drives that are plugged in.
The possibilities are pretty limitless; the first point is actually reasonably likely, as is the last.
I can haz tl;dr?