Mis-understandings about Software Restriction Policies (SRP)

[quote="ssj100"][quote="MrBrian"]

ssj100 wrote:Welcome to the forums MrBrian! And yes, if you read through this entire thread (it can be confusing sorry) I actually (eventually) agreed with you haha.

I see. I hope Microsoft changes default permissions in Windows 8 so that these folders don't need special attention anymore.

Thank you for the warm welcome ssj100 and Hawkwind .

@MrBrian:

May I also add a warm welcome.

@ssj100:

I thank somewhere,someplace,I asked you this before,(but I forgot where)

If I end up losing ShadowDefender,do you thank I would gain anything by implementing SRP in my administrator account?

As I have said,I am not keen on setting up LUA on this old Windows install.

noor

noorismail wrote:@ssj100:

I thank somewhere,someplace,I asked you this before,(but I forgot where)

If I end up losing ShadowDefender,do you thank I would gain anything by implementing SRP in my administrator account?

As I have said,I am not keen on setting up LUA on this old Windows install.

noor

To be honest, I wouldn't recommend implementing SRP in an admin account unless you really know what you're doing. Otherwise, you're likely to get frustrated and wonder why things aren't working properly etc.

I don't see why you wouldn't be able to continue using Shadow Defender though. If you're thinking of getting rid of it voluntarily, then you'll need to re-think your security strategy (setup/approach). Does the fact that you're asking about SRP mean that you are interested in an anti-execution mechanism of protection? There are other third-party anti-execution programs available, but few are free and even fewer are still supported and developed. Another reason I ask is that SRP does not replace Shadow Defender.

Well,I have of course been interested in anti-executables,since using the one
built into Returnil 2008.
I have also used ProcessGuard off and on,in the past.

SRP is fascinating to me because it is free,uber-effective,with no resource overhead.

noor

noorismail wrote:Well,I have of course been interested in anti-executables,since using the one
built into Returnil 2008.
I have also used ProcessGuard off and on,in the past.

SRP is fascinating to me because it is free,uber-effective,with no resource overhead.

noor

If you use SRP in your admin account (Windows XP), you'll need to work out a way to conveniently disable it whenever you want to run new executables (eg. when updating programs or installing new programs). The fastest and easiest way I could think of (yes, I initially used SRP in an admin account when I first started using it!) is to place a shortcut of "Local Security Policy" in your Quick Launch bar or on your desktop. The thing is that using SRP as an anti-executable mechanism doesn't quite make sense in an admin account - remember, SRP allows anything in C:\Program Files and C:\Windows to execute (how else can you run anything otherwise?). And as an admin, you can write to C:\Program Files and C:\Windows (as a limited user, you can't). So all a malware has to do is to write to either C:\Program Files or C:\Windows and then it will be allowed to execute and hurt your system as it pleases (with admin rights too).

A good example is the .wmf exploit back in late 2005. From my understanding, this is how one such variant infected a system:
1. Admin account with no anti-execution mechanism and no Hardware DEP
2. Obtain infected picture file
3. Double click on picture file (with some exploit variants, the user didn't even need to double click the infected file. Simply just having the file on the system was enough to cause spontaneous infection in certain situations).
4. Overflow exploit process initiates
5. Dropper executable file is spontaneously downloaded from a malicious internet server
6. Dropper executable file is placed in path "C:"
7. Dropper executable file spontaeously executes and owns the system (well actually, from what I remember reading, it opened up your web browser and attempted to do some dodgy advertising to trick you into losing your money/identity.

So let's see how this clever exploit could be mitigated or even stopped at each step:
1. Run as limited user
2. Don't obtain infected picture files haha. I know I know, easier said than done.
3. Don't double click on infected picture files haha (or double click them in full blown VM's or light system virtualisers).
4. Ensure you enable Hardware DEP for all programs and services ("OptOut" should be sufficient)
5. A Firewall could potentially stop this, although I feel this could be easily circumvented particularly if running as an admin
6. As a limited user, the executable file cannot be placed in path "C:"
7. With SRP enabled, the file cannot execute (since it's not in C:\Program Files or C:\Windows)

As you can see, even if you had no other security software/hardware, simply running as a limited user would have prevented the exploit from running fully (step 6.). Having SRP enabled in an admin account would also have stopped the exploit from running. However, if the exploit was programmed a little bit better, it could have dropped the executable file in C:\Program Files or C:\Windows. And since SRP allows execution from those folders, it would not protect you at all.

Therefore, the conclusion is that running as a limited user with SRP enabled gives the best protection. Hope that helps. If anyone is confused, please feel free to ask for clarification. Cheers.

thanks,ssj100,yes very helpful,and a little sobering.

LUA and SRP are like a suite,you really need both for full benefit,with the nod going to LUA if only one is used.

Like the old Irish Proverb: "Faith and Reason are like the two shoes on your feet.
You can go further with both,than just one"!!

There are other third-party anti-execution programs available, but few are free and even fewer are still supported and developed. Another reason I ask is that SRP does not replace Shadow Defender.

The topics on wilders are a really serious wake up call for what seems to be an impeding avalaunch of LV destroyers. Basically the added seurity of using an admin account "to do anything" and still be protected is nothing but a mirage. No type of driver filtering will be sufficient to stop these well tailored nasties from communicating directly with the hdd disk controller hence, we are faced with what seems to be an inherent flaw --(leading to a futile cat and mouse games)-- in the current deisgn of these reboot to restore programs. Rmus' post sheds light on the depressing state of things as they are currently: http://www.wilderssecurity.com/showpost.php?p=1706057&postcount=52

What I found to be the only potent anwser to these threats is AE. But I am currently faced by a dilemma...
1- I don't know how good sandboxie compares as a standalone antiexecutable. Does it stop all types of executing filetypes??scripts,reg dll and exe's I heard autorun can still run and wreak havoc (even under SRP!!). If so, then what can reall stop these from running? can it be trusted as a full fledged solution for webfacing apps in terms of AE

2-If not a good anwser to the AE solution, then what would you recommend ssj? what is a free, yet continually developed and effective AE that can be used alongside sbie?

3- I am doubtful about sandboxie's skill as an AE on x64; the reason being is-- would it only give programs a "recommendation" not to execute or can it enforce non execution? I currently lack the knowledge to anwser this question..

4-would malware that escapes from a sandbox with LUA enabled be able to elevate itself? or would it be constrained with the reality that its admin privildeges were already removed --in a permanent sense by sbie?

5- Would having 2 robust AE's be better than running one, just in case one misses sthg?

I am currently enjoying the flexibility of being able to tweak, uninstall/install and update on my admin account and of running webfacing/driveby susceptible vectors under sbie. I dont use UAC as i heard that almost anything and everything out there can bypass this. hate how it annoys me with popups yet fails under real intent cirumstances (correct me if im wrong).

I run shadow defender as my main 'big gun' backstop where if sandboxie fails. However the prospect of it not including an AE of its own currently, is worrying me due to breaches we hear about. I will probably feel alot better if shadow defender is solidly being developed...

I hate how returnil doesn't give one an option to use their own AV, by not excluding it from installation which can cause unseen conflicts with resident scanner of choice. I also abhor how it takes 20 times the resources in ram and hdd space to accomplish the same thing as SD. the only thing it includes worth mentioning is their AE, which I'm not sure that I have

I never run anything untrusted on my computer fullstop. My nightmare is drivebys

Rico wrote:1- I don't know how good sandboxie compares as a standalone antiexecutable. Does it stop all types of executing filetypes??scripts,reg dll and exe's I heard autorun can still run and wreak havoc (even under SRP!!). If so, then what can reall stop these from running? can it be trusted as a full fledged solution for webfacing apps in terms of AE

I thought I had already answered this question somewhere on this forum, but apologies if I haven't. As far as I know, Sandboxie will only block .exe executable file types. However, keep in mind that a lot of scripting executables make use of Windows' own scripting mechanisms (eg. wscript.exe, cscript.exe, cmd.exe), and therefore Sandboxie would be effective against these. However, keep in mind that whenever a file leaves the sandbox (eg. you recover a file on to your REAL system), you will no longer be under Sandboxie's protection.

As far as I know, autorun viruses have always used some form of execution to cause infection. Sure, SRP will not block the autorun itself (you can do that by simply disabling autorun) but it will block any (malware) execution that is not white-listed. I repeat, SRP is a very powerful anti-executable when configured well (see my security setup/approach post). Remember, if it can't execute, it can't infect.

Rico wrote:2-If not a good anwser to the AE solution, then what would you recommend ssj? what is a free, yet continually developed and effective AE that can be used alongside sbie?

That is a good question, and the answer is I don't know of any free third party AE solution that is continually and actively being developed (I remember trying out various ones in 2009 when I was still searching for a good security setup/approach. Unfortunately, I can't recall their names, but they were generally either unstable, buggy or not being developed anymore). Happily for myself, I use SRP, and will use AppLocker when I eventually migrate to Windows 7 on my REAL system (possibly around 2014 if the world still exists haha).

Rico wrote:3- I am doubtful about sandboxie's skill as an AE on x64; the reason being is-- would it only give programs a "recommendation" not to execute or can it enforce non execution? I currently lack the knowledge to anwser this question..

I'm not 100% sure about this, but I'd say generally Sandboxie would be highly effective at blocking execution even on 64-bit. I think the 64-bit weakness is more related to drivers and services - so if a malcious process calls out eg. a windows service, Sandboxie can only "recommend" it to stay in the sandbox. Although if you have "Drop Rights" enabled, I think this process should be blocked easily by Sandboxie.

Rico wrote:4-would malware that escapes from a sandbox with LUA enabled be able to elevate itself? or would it be constrained with the reality that its admin privildeges were already removed --in a permanent sense by sbie?

I don't quite understand your question here. If you are in a native LUA, you are running with limited rights system-wide. Anything running in Sandboxie is also being run with limited rights.

Rico wrote:5- Would having 2 robust AE's be better than running one, just in case one misses sthg?

To an extent, yes. But be careful with potential conflicts when using more than one third party security solution. Happily, my system-wide anti-executable is a tool built into Windows itself (SRP), and I only have one third party security program installed (Sandboxie).

Rico wrote:I am currently enjoying the flexibility of being able to tweak, uninstall/install and update on my admin account and of running webfacing/driveby susceptible vectors under sbie. I dont use UAC as i heard that almost anything and everything out there can bypass this. hate how it annoys me with popups yet fails under real intent cirumstances (correct me if im wrong).

I don't know much about the strength of UAC. With regards to "enjoying the flexibility of being able to tweak, uninstall/install and update", I'm guessing you're using Windows 7? If so, you can still do all that in a limited user account (Standard User Account) by the "Run as Administrator" command (eg. via right click context menu). For me, I use SuRun on Windows XP, and it works very well. However, how often are you realistically tweaking/uninstalling/installing/updating? If you're doing it everyday, the question that comes to my mind is what else are actually doing with your computer haha. Fact is, once you have all the programs you need installed, there's no need to require admin rights most of the time.

Rico wrote:I run shadow defender as my main 'big gun' backstop where if sandboxie fails. However the prospect of it not including an AE of its own currently, is worrying me due to breaches we hear about. I will probably feel alot better if shadow defender is solidly being developed...

I hate how returnil doesn't give one an option to use their own AV, by not excluding it from installation which can cause unseen conflicts with resident scanner of choice. I also abhor how it takes 20 times the resources in ram and hdd space to accomplish the same thing as SD. the only thing it includes worth mentioning is their AE, which I'm not sure that I have

I never run anything untrusted on my computer fullstop. My nightmare is drivebys

"drivebys" are easily contained by using Sandboxie and an anti-execution mechanism. In fact, all you really need is Sandboxie. Most people seem to know how to use Sandboxie for their web browser, but less seem to know how to use it for USB/CD/DVD devices. If you check my security setup/approach post, you'll notice that under Sandboxie (steps 12 and 13), I have made the recommendation to also sandbox these devices. I've been doing that pretty much from when I first started using Sandboxie just over a year ago, and I'm pretty sure I've spammed the Sandboxie forum about this haha. So it was surprising that people on other forums are only just discovering this.

EDIT: come to think about it, all you really need is Firefox with NoScript (or equivalent) to block all web-based drivebys.

http://www.wilderssecurity.com/showthread.php?t=251629&page=2

found the disscussion you had years ago on wilders regarding AE. Let me just say how you are a great and knowledgeable fellow in these matters, you also seem to be willing to ask what no one had before you. Thanks to the many topics initiated by you on wilders, I have become more learned, you are a valuable member to the online security community keep it up!!. There is nothing that I think of and search on wilders unless i find that you have already pursued

clicking on the many links i find that most of the programs are archaic/dead, so I gues Imma stick with SBIE start/run probably the most decent stuff around

Thanks Rico. Yes, that was (in my humble opinion), one of the many good threads I started. I learned a lot too. I think that thread was when I started thinking about using SRP instead of a classical HIPS.

Essentially I realised that a classical HIPS is pretty useless if you have a good security approach and handle newly introduced files with intelligence. Fact is, even very knowledgeable folk can't be 100% sure if a process is trying to be malicious or not (when they analyse it through a classical HIPS).

If a program is trusted and safe (eg. a program obtained from a reliable and reputable source), I really do not see the point of trying to control every inch of its behaviour with a classical HIPS. It's a trusted and safe program for goodness sakes haha. I do get bored sometimes, but I don't get as bored as to slave over trusted and safe processes on my computer. If I did, I'd have become a slave to my computer (when it should be the other way around!).

I do recall trying out Faronics Anti-executable version 2, but soon became disappointed with it - I discovered that it didn't block command prompt (eg. via cmd.exe) or other scripting executables (eg. via vbscript, wscript.exe). Then I came across SRP and I've never looked back since.

The fact is that only POCs have been able to bypass SRP (keeping in mind that SRP is nearly 10 years old and hasn't really been updated!) and these POCs rely on specific user settings to be present - eg. macros need to be allowed to run in Microsoft Excel or Powershell needs to be installed and allowed to run. All these can be blocked if you know what you're doing. But anyway, why go to so much trouble? There've never been examples of any real-world malware that can bypass (a pretty much default) LUA + SRP.

And with Windows 7 (Ultimate), we have AppLocker which is yet to be bypassed by even a POC. I'd like to know if Didier Stevens has had any success bypassing AppLocker on 64-bit.

Hi, ssj100.

I noticed in your security setup that you use a disallowed rule for RunAs.exe in SRP to prevent elevating privileges, but there is another good reason if you are not already aware. RunAs also has a trustlevel feature that effectively bypasses any existing SRP rule. The command prompt command looks as follows:

runas /trustlevel:"Unrestricted" c:\Windows\Notepad.exe

RunAs wont prompt for admin credentials when using the trustlevel function. You can try this yourself by first creating a disallowed hash rule for notepad.exe, then go to the command prompt and use RunAs. Watch notepad start right before your eyes.

Another approach a person might consider regarding folders like windows/temp is to address permissions at the very root of the C drive, as opposed or in addition to SRP disallow rules. From the properties of the main C drive give administrators and the system full control, and give users read and execute control, but no writing or ability to change permissions. Delete any other users or groups that may be listed. Select the option to replace the permissions on all subfolders and files with those you just created.

Of course, users still need a place to write. Go to your limited user's folder and change its permissions to allow reading and writing, but no executing or changing permissions. Again, select the option to replace the permissions on all subfolders and files with those you just created.

With exception to USB drives and the like, this essentially duplicates SRP and makes for a strong duo when combined with SRP. Two layers of can't write where execute and can't execute where write. In fact, if you create an exe file on a users desktop you'll find that file permissions intercept a double click before SRP.

File permissions are an espessially important tool for users of Windows versions that don't include SRP.

Edited to add: You'll also need to set permissions for C:\recycler the same as is done with the limited user's folder or the reecycle bin will be broken.

Tranquility wrote:Another approach a person might consider regarding folders like windows/temp is to address permissions at the very root of the C drive, as opposed or in addition to SRP disallow rules. From the properties of the main C drive give administrators and the system full control, and give users read and execute control, but no writing or ability to change permissions. Delete any other users or groups that may be listed. Select the option to replace the permissions on all subfolders and files with those you just created.

Of course, users still need a place to write. Go to your limited user's folder and change its permissions to allow reading and writing, but no executing or changing permissions. Again, select the option to replace the permissions on all subfolders and files with those you just created.

With exception to USB drives and the like, this essentially duplicates SRP and makes for a strong duo when combined with SRP. Two layers of can't write where execute and can't execute where write. In fact, if you create an exe file on a users desktop you'll find that file permissions intercept a double click before SRP.

File permissions are an espessially important tool for users of Windows versions that don't include SRP.

Edited to add: You'll also need to set permissions for C:\recycler the same as is done with the limited user's folder or the reecycle bin will be broken.

Thanks for this information Tranquility - it sounds very logical and sound. I may employ this at some stage (after first taking an image of my drive). I'd like to know what Sully, wat0114, MrBrian etc think about this. It seems like it would work well with Windows 7 too?

Tranquility wrote:Hi, ssj100.

I noticed in your security setup that you use a disallowed rule for RunAs.exe in SRP to prevent elevating privileges, but there is another good reason if you are not already aware. RunAs also has a trustlevel feature that effectively bypasses any existing SRP rule. The command prompt command looks as follows:

runas /trustlevel:"Unrestricted" c:\Windows\Notepad.exe

RunAs wont prompt for admin credentials when using the trustlevel function. You can try this yourself by first creating a disallowed hash rule for notepad.exe, then go to the command prompt and use RunAs. Watch notepad start right before your eyes.

Thanks, I did not realise this.

I haven't toyed with Windows 7, but assuming it's still using NTFS and permissions are user accessable then I would have to say yes.

Have you noticed anything breaking or any eg. Event log errors popping up by doing the following?:

From the properties of the main C drive give administrators and the system full control, and give users read and execute control, but no writing or ability to change permissions. Delete any other users or groups that may be listed. Select the option to replace the permissions on all subfolders and files with those you just created.

Of course, users still need a place to write. Go to your limited user's folder and change its permissions to allow reading and writing, but no executing or changing permissions. Again, select the option to replace the permissions on all subfolders and files with those you just created.

Also (and for example), does prefetching still work in a LUA etc?

It's windows as usual. No red flags in the event viewer. I wouldn't know I changed anything until I bump into it by double clicking a program I just downloaded to my desktop. "Oh yeah. That's right. I'm in my limited account." No different from using SRP.

I did have to fix the recycle bin. Well, I didn't have to, but I like the second chance the recycle bin affords.

Thanks for the information, but I think I'll be sticking with my current setup for now (I've got SRP after all). I'm not an expert with file permissions, but deleting other users/groups somehow makes me think that certain things will break (you've already pointed out the recycle bin as something you noticed breaking).

In any case (and based on your experiences), your method would be a good alternative for Windows users not running Pro or Ultimate etc versions (that is, versions that don't have SRP easily accessible). Also, you could argue that applying your method would provide even more protection even if you have SRP enabled. Of course, it would do nothing to increase protection against privilege escalation attacks, but it may increase protection against people like Didier Stevens who appear to enjoy demonstrating POCs showing how to bypass SRP haha. Of course, even his methods of bypassing SRP require certain specific variables to be present.

By the way, Tranquility, let me pick your brains for a moment (since wat0114, Sully etc don't seem to visit this forum anymore):

Do you know what DefenseWall is (and how it works)? If so, can you help me understand why Kees is attempting to compare it with LUA + SRP?:
http://www.wilderssecurity.com/showpost.php?p=1717400&postcount=143

DefenseWall isolation goes beyond LUA/SRP.

So yes can be compared in the sense that a Hummer and a tank both provide transport and safety to soldiers, but they are from a different league to defend against malware.

I think he implies that DefenseWall is the tank, while LUA/SRP is the Hummer. This isn't quite right, and in fact, you could say it's completely the opposite. From the numerous posts I have read of Kees, he doesn't seem to use SRP as an anti-executable (which I think is the primary reason for using it in most corporate facilities). Either that, or he isn't aware of it?

The fact is that LUA/SRP can be setup to be a Nuclear bunker (if DefenseWall is the Tank). DefenseWall doesn't act like an anti-executable - it tends to (always) allow you to execute a program. SRP, however, can stop execution, and therefore prevent any (potential) malware from even trying to run in the first place.

The fact is that DefenseWall has been directly bypassed numerous times by various attack vectors. Check out the latest one here:
https://ssj100.forumotion.com/security-f7/vulnerability-in-windows-shell-could-allow-remote-code-execution-t187.htm#1302

And therefore, it has been patched numerous times to block these bypasses, and the developer will have to continue doing this time and time again. Why is this? Simply because it conceptually allows initial execution. Don't get me wrong - it is extremely powerful protection despite this. However, the most powerful (and therefore potentially more restrictive and more problematic) method is to simply deny initial execution.

Ultimately, my point is that comparing LUA + SRP to DefenseWall doesn't make sense.

I haven't used the program so I really can't comment on it. SRP and file permissions seem to provide pretty good protection from unwanted executions so I just stick with that.

That's all good. I was merely asking so that you could back me up (and trust me, you would) if you understood how DefenseWall works. It doesn't deny initial execution, simple as that. And as has been said time and time again by professional malware and anti-malware writers, there are many ways to bypass any protection if initial execution is allowed.

DefenseWall is essentially a Classical HIPS without the pop-ups, except it doesn't pop-up asking if you want to allow initial execution - it only pops up asking if you want to run it trusted or untrusted. DefenseWall does the thinking for you from then on (which means that you rely 100% on the programmer) and that's why you usually don't see any pop-ups thereafter. For the configured Classical HIPS, correctly allowing and denying pop-ups can give you at least the same level of protection as DefenseWall.

I was first made a believer in LUA's when a person tested a bunch AV software against a package of malware he found contained in a self extracting zip. Everyone of the about ten he installed and tested failed to stop it. What is worse is they themselves were disabled by the malware. He was running the tests from an admin account in XP. I ran the zip from inside my limited account without any AV software and the malware failed to install.

Now to be sure, we would be fools to think LUA and SRP is bullet proof, but one thing is for sure - all bets are off once you execute. So I focus on execute prevention using "can't write where I can execute and can't execute where I can write". There are areas where this approach is useless like Flash, .Net, Java, Office macros, and probably Silverlight that run right inside of our execute restrictions via the helpfull hands of their respective host applications. The only limitations to what these applets can and can't do are determined by LUA rights and the applet's inability to circumvent those rights.

So perhaps one area to consider when evaluting a HIPS type product is what can and can't do to help shore up these areas, if it is even possible?

Tranquility wrote:Now to be sure, we would be fools to think LUA and SRP is bullet proof, but one thing is for sure - all bets are off once you execute. So I focus on execute prevention using "can't write where I can execute and can't execute where I can write". There are areas where this approach is useless like Flash, .Net, Java, Office macros, and probably Silverlight that run right inside of our execute restrictions via the helpfull hands of their respective host applications. The only limitations to what these applets can and can't do are determined by LUA rights and the applet's inability to circumvent those rights.

LUA + SRP certainly seems bullet-proof in the real-world though (when configured appropriately). I've not read or come across a single real-world malware that bypasses it.

With regards to the approach being useless with Flash etc, I think you are mistaken - SRP will allow Flash etc to run, but it will still block any foreign PE executable process with ease. Perhaps what you are thinking of is how SRP can be disabled (which isn't really a bypass, since you're not actually testing SRP anymore - it's been disabled, so of course it has no chance) via Office Macros or Powershell ( https://ssj100.forumotion.com/windows-hardening-f5/blocking-powershell-t7.htm#21 ). However, being aware of these potential holes that allow SRP to be disabled will help prevent bypass.

What I'm think of is all it takes to bypass LUA and SPR is a privilege escalation exploit, and any one of the mentioned applications are excellent vehicles to deliver it. There are many examples. Even the old Blaster worm walked right past them and in its hay-day all you had to do was connect to the internet and you were hosed in minutes.

http://en.wikipedia.org/wiki/Blaster_(computer_worm)

So all you need is a system level exploit, like the more recent DOS virtual machine exploit.

http://en.wikipedia.org/wiki/Virtual_DOS_machine

This one walks right past LUA, SRP, DEP, and address randomization.

Tranquility wrote:What I'm think of is all it takes to bypass LUA and SPR is a privilege escalation exploit, and any one of the mentioned applications are excellent vehicles to deliver it. There are many examples. Even the old Blaster worm walked right past them and in its hay-day all you had to do was connect to the internet and you were hosed in minutes.

http://en.wikipedia.org/wiki/Blaster_(computer_worm)

So all you need is a system level exploit, like the more recent DOS virtual machine exploit.

http://en.wikipedia.org/wiki/Virtual_DOS_machine

This one walks right past LUA, SRP, DEP, and address randomization.

Well, of the two examples you've given, I must say that you are again mistaken (see my justification below). However, I do understand where you're going with "privilege escalation". However, generally speaking, in order to gain admin privilege in a limited account, something still needs to be executed. SRP would still block this execution before anything gets elevated, unless there was a kernel level exploit (see below). In the case of a kernel level exploit, nothing can be done (apparently) anyway. So saying that it walks right past LUA, SRP, DEP etc isn't fair haha - it would walk past any defence system. However, it appears that many (all?) kernel level exploits require local/physical access to the computer (and this wouldn't count as a genuine bypass, since if someone has local/physical access to your computer, they can do much more harm than "bypass your security setup").

I'm not sure on exact details, but the Blaster worm is presented as using a Buffer overflow exploit:
http://en.wikipedia.org/wiki/Blaster_%28computer_worm%29

The worm spread by exploiting a buffer overflow discovered by the Polish cracking group...

I don't think many systems had genuine Hardware DEP enabled back then, so this protective mechanism alone may have stopped it dead. And besides, SRP would easily block any PE executable that this buffer overflow exploit would attempt to subsequently run.

With regards to the DOS virtual machine exploit, this turned out to be a kernel level exploit that required local access:
http://www.h-online.com/security/news/item/Windows-hole-discovered-after-17-years-Update-908917.html

...that allow an unprivileged 16-bit program to manipulate the kernel stack of each process via a number of tricks.

http://www.microsoft.com/technet/security/advisory/979682.mspx

Vulnerability in Windows Kernel Could Allow Elevation of Privilege

http://www.microsoft.com/technet/security/Bulletin/MS10-015.mspx

To exploit either vulnerability, an attacker must have valid logon credentials and be able to log on locally. The vulnerabilities could not be exploited remotely or by anonymous users.

Check out similar vulnerabilities back in 2004:
http://www.symantec.com/security_response/vulnerability.jsp?bid=11369

To exploit this vulnerability, an attacker requires local interactive access to an affected computer.

http://osvdb.org/show/osvdb/5258

The issue is triggered when an attacker causes code to run in Virtual86 mode without first initializing a Virtual DOS Machine, which may allow the attacker to derefernce a null pointer and execute arbitrary code in kernel space.

Local Access Required