This entry notes that there are a bunch of products that use 'rootkit' behavior.
Sony DRM was an egregious example of a software provider changing the behavior of the system in unusual ways. The dirty little secret of Windows programming is that lots of vendors change the behavior of other programs on a Windows system in ways that make it difficult to distinguish between good and malicious activity.
Back in the good old days of Windows 3.1, it was easy for other programs to modify another program. Of course, you aren't supposed to do that in modern operating systems such as NT, 2000, or 2003. Processes are supposed to be separate entities so that incorrect behavior by one program doesn't crash or hang the whole system.
The only problem with that is that folks like Jeff Richter and others have documented all of the ways for a program to violate this normal constraint, and IT HAPPENS ALL THE TIME.
I was reminded of this a couple of times in the last few weeks. First, Google Toolbar hooks a number of functions in Internet Explorer. There are a number of reasons why they might do it, but they do it in a way that is similar to what a hacker might do: namely they allocate some memory to perform the hook and then sometime later they change the permissions on the memory to be executable. At least they mark it as executable at some point. BUT the problem is that suppose that a hacker is trying to get some injected code to run, they may do exactly the same time: namely they find some memory that has been allocated before and they mark the area as being executable.
Stuff like this makes it more difficult to tell good from bad behavior in-memory. It would be nice if the platform vendor established a protocol for making inserting these kinds of hooks that was difficult for hackers to emulate.
Sony DRM was an egregious example of a software provider changing the behavior of the system in unusual ways. The dirty little secret of Windows programming is that lots of vendors change the behavior of other programs on a Windows system in ways that make it difficult to distinguish between good and malicious activity.
Back in the good old days of Windows 3.1, it was easy for other programs to modify another program. Of course, you aren't supposed to do that in modern operating systems such as NT, 2000, or 2003. Processes are supposed to be separate entities so that incorrect behavior by one program doesn't crash or hang the whole system.
The only problem with that is that folks like Jeff Richter and others have documented all of the ways for a program to violate this normal constraint, and IT HAPPENS ALL THE TIME.
I was reminded of this a couple of times in the last few weeks. First, Google Toolbar hooks a number of functions in Internet Explorer. There are a number of reasons why they might do it, but they do it in a way that is similar to what a hacker might do: namely they allocate some memory to perform the hook and then sometime later they change the permissions on the memory to be executable. At least they mark it as executable at some point. BUT the problem is that suppose that a hacker is trying to get some injected code to run, they may do exactly the same time: namely they find some memory that has been allocated before and they mark the area as being executable.
Stuff like this makes it more difficult to tell good from bad behavior in-memory. It would be nice if the platform vendor established a protocol for making inserting these kinds of hooks that was difficult for hackers to emulate.
0 Comments:
Post a Comment
<< back