An interesting way to bypass SRP (and potentially other security setups)

[ssj100]

I came across an interesting form of "exploitation" when reading Didier Stevens' most interesting blog. Unfortunately, a lot of stuff he writes goes right over my head. However, I do understand some of what he writes to an extent.

Basically, the below exploitation (see link at bottom) technique has come about from his attempts at bypassing SRP, even in a LUA - and he has been successful at creating such a POC. The key is that the .dll is not required to be "injected" (where a lot of anti-malware products would then alert the user), but instead it is merely "loaded".

For my own personal setup, I am well covered even from this type of attack because I combine Sandboxie with LUA + SRP. Since Sandboxie forces containment/blocking of all malware threat-gates, Didier Stevens' unique attack would fail miserably. The only realistic possible hole is if I "recovered" an unknown/untrusted file (that contains his unique attack) out of a sandbox and run the file unsandboxed. Again, this is easily solved by always opening any (untrusted/unknown) newly introduced file with a sandboxed explorer.exe - this is easily achieved with great convenience by having a short-cut (in eg. the Quick Launch bar) that opens up a sandboxed desktop for running or manipulation of the newly introduced file.

My question here is whether this technique could be used not just to bypass SRP, but also to perform more malicious insults like destroying system files. I suspect that this would be fairly easily done, in relative terms.

So if this technique can be used to compromise your system, what are ways (apart from my own setup and approach) to prevent it? The "scary" aspect of this technique is that ANY file type could contain the code (if the file type was successfully exploited). So we're not just talking about executable file types here. In theory (I think) you could open a .txt file or a .jpg file or a .xml file etc, and get struck down by a clever malicious malware writer.

I suspect a tightly configured classical HIPS would block this easily, such as Defense+ or Malware Defender, but I'm not 100% certain. I suspect DefenseWall would block this as long as the file was "untrusted", but again, I'm not sure about this. Would Xiaolin or Ilya please like to comment?

Now as Joeythedude would suggest, it is important to put things into perspective. This is merely a POC. You are probably more likely to get struck by lightning than get infected by an attack such as this. I am merely posting this out of curiosity and interest. Thanks for reading, and here's the link:

http://blog.didierstevens.com/2008/10/23/excel-exercises-in-style/

[Sully]

I saw that before. I think I shall just wait until the POC is out and about before worrying. There are bigger fish to fry as they say.

Sul.

[aigle]

dll loading wil bypass most HIPS as though many of them can monitor it but it,s not practical to use this feature in daily life.

Sandboxes wil stop this as they stop untrusted dll loading, but they wil obviously fail if the user wil execute the file as trusted and that might be quite common.

[Windchild]

-{ Quote: "
Basically, the below exploitation (see link at bottom) technique has come about from his attempts at bypassing SRP, even in a LUA - and he has been successful at creating such a POC. The key is that the .dll is not required to be "injected" (where a lot of anti-malware products would then alert the user), but instead it is merely "loaded"." }-

Well, it doesn't really work that way. There is no DLL file involved at all. Not only is there no DLL "injected" into another process, there also isn't any DLL loading at all. In fact there just plain isn't any malicious DLL file involved. Instead, the attack is based on running a macro to inject and execute shellcode. In other words, instead of loading a DLL file, this attack just writes some code of the attacker's choice into a process that you have write access to and then gets the code executed. No DLL, no nothing.

How interesting is this, though? Consider that for this to happen, the code that tries to do this has to be executed first. In the case of this example, the malicious Office macro would have to be executed before it could attempt to perform this attack. And who says you have to let that macro execute? ;)

-{ Quote: "My question here is whether this technique could be used not just to bypass SRP, but also to perform more malicious insults like destroying system files. I suspect that this would be fairly easily done, in relative terms." }-

If you can execute arbitrary code, you can of course attempt to do all kinds of things, like destroy system files. In this case, though, that wouldn't work. Why? Because one is running as a limited user, and limited users don't have permissions to destroy system files (only read & execute access to system files is allowed for LUA by default). We can't assume one is running as admin, because then there would be no need at all for such elaborate attacks to bypass SRP, when you could achieve the same just by writing your badware file in the Windows folder and executing it from there much faster and easier. But you could do other things much more useful: after patching SRP checking off, you could just load any program you want and execute it freely in the context of the limited user account - keyloggers, spam bots, DDoS bots, rogue AV, everything goes. Again, though, those would be limited by the privileges of the limited user account, so they couldn't achieve a system-wide infection and would be trivial to detect and remove.

-{ Quote: "So if this technique can be used to compromise your system, what are ways (apart from my own setup and approach) to prevent it?" }-

Tons of ways exist to help prevent attacks like this.

The first and most obvious is of course: don't execute untrusted code. IOW, someone sends you a word document, and it seems to contain a macro. And you don't know what that macro does. How about just not executing the macro before you do know what it does, and know that it doesn't do nasty things? This will work against social engineering attacks, but obviously won't help against attempts to exploit some browser/plugin vulnerability to do a drive-by attack.

If common sense doesn't work, then it's up to software. For this example (Office macro performs the attack), any software that blocks Office macros from running automatically would already stop the attack from happening without user approval. Microsoft Office itself could be used to block the macro. If you're going to execute that macro without knowing what it does, then you need something that prevents the macro from writing into the memory of any processes you wish to protect, to prevent the attack from working. If you were running a virtual machine to execute the macro, for example, the attack wouldn't be able to reach the processes in the real system, so it wouldn't be a very useful attack.

Not really a big deal attack in any way.

-{ Quote: "The "scary" aspect of this technique is that ANY file type could contain the code (if the file type was successfully exploited). So we're not just talking about executable file types here. In theory (I think) you could open a .txt file or a .jpg file or a .xml file etc, and get struck down by a clever malicious malware writer." }-

No. Where did you get the idea that any file type could be used for this? You can't put some malicious script in a .txt file and have the script magically execute when you open the file in Notepad. For that to happen, the program you use to open the text file needs to either 1. try to execute the script because that's how the program was made to work (Office software will try to execute macros, of course, since that is what they do, assuming macro security settings don't prevent it) or 2. have an exploitable vulnerability that makes the program execute the script when you format the script in the right way. This technique isn't special in this regard in any way. You can't exploit file types - you can only exploit the software that handles those file types. If you can. In the case of text files, for example, good luck finding the needed vulnerability in Notepad. ;D Of course, if one was so inclined, they could write themselves a "text editor" that not only displays text files but also tries to randomly execute everything found in them, and that would make attacks like this work from text files. But my suggestion would be: don't do that. ;)

So, in summary, the attack isn't very interesting. Nor very scary. It's the same as they all are: if you let untrusted code execute, it can do stuff. Not surprising. However, it should make one realize that nothing is invulnerable. This attack in particular shows how you can get around even a very tight software restriction policy, and many other security software products that don't watch out for attacks like this. And even for those security software that do, the problem remains social engineering attacks. Sooner or later, most users want to do something that requires them to trust a file. You can't install a graphics card driver, for example, if you block it with some HIPS or toss it in a sandbox. And you can't trust that a virtual machine could be used to analyze what the file does before executing it in a real system, because it's not difficult to code routines to check for virtual machines and sandboxes. You could make that task more difficult for the bad guy by using a customized virtual machine, but how many are going to do that? So, ultimately it all comes down to either trusting the source or performing very extensive analysis that will require a lot of skill and a lot of time. Since practically everyone will have to choose option 1, it makes sense to be rather careful with who you trust.

[wat0114]

-{ Quote: "
Where did you get the idea that any file type could be used for this? You can't put some malicious script in a .txt file and have the script magically execute when you open the file in Notepad. " }-

Hi Windchild,

what about that technique, I forget what it's called, maybe OLE or meta, something like that, where executable file types can be hidden within other, non-malicious file types such as .jpg?

[Windchild]

-{ Quote: "First of all, thanks very much for the clarifications Windchild! It's great to have such an expert like you around." }-

"Expert" is relative, too! :o ;D

-{ Quote: ""Interesting" is relative mate, just like everything in life. You might find looking at a live beating heart (eg. seen in coronary artery bypass grafting surgery) "interesting", while it would be fairly boring for me." }-

My point in saying that the attack isn't very interesting was that it's not something to worry about. It isn't really special: there are many ways to prevent and limit the impact of attacks like this. And those methods are pretty much the same as with all other attacks.

Beating hearts, though... A live beating heart I've seen. That wasn't very interesting. I'd pay money, though, to see a dead beating heart! Night of the Living Dead! ;D

-{ Quote: "Gotta love that LUA!" }-

Indeed. Where LUA doesn't entirely prevent something nasty, it often helps limit the impact and/or makes the job easier for third party security software. Least privilege should be a key part in any security policy. Of course, one can certainly choose to operate without, but that does involve some issues that even very sophisticated HIPS and other security products won't solve - like the issue of users being able to access and even modify each other's files, which is not necessarily something you'd want.

-{ Quote: "That's fairly obvious, but as I said, I was trying to think of other (unknown) ways that this method could be used. There are many programs out there, and we never know which program could be exploited so that this attack would succeed." }-

And that's the nature of security - there are uncertainties and surprises. Some remote code execution vulnerabilities could be used to perform this attack. Some software that allows you to write and/or run scripts could be used. And so on. But, as usual, we have to consider how this attack could happen against a real system. And that boils down to either social engineering or exploiting vulnerabilities to do a drive-by. Social engineering attacks ought to be easy to avoid for someone who would actually know about something as obscure as this attack: just don't execute untrusted code, even if it's "just" an Office macro. Doing that prevents all those "install this codec to view this cool vid" and similar attacks that one could use to pull off an attack like this. And the drive-by attacks aren't that bad, either: keep software patched so you don't fall for old vulnerabilities, and try to configure software that is likely to be targeted so that the exploits are less likely to work. For example, simply disabling ActiveX in the Internet Zone in Internet Explorer prevents a vast number of attacks against IE - even if your IE is vulnerable against some unpatched ActiveX exploit. Remote exploits against Adobe Reader for example? Disable the Adobe PDF browser plugin, and you'll kill practically all of those attacks, or at least turn them into a kind of social engineering ("Hmm, a random site I've never been on is telling me to download/open a PDF file even though I didn't click to download any PDFs. I wonder what I should do...") Do enough of that and you'll end up in a situation where it's very difficult for the attacker to get the actual exploit code running, even if you're not running any security software at all. That's pretty much the kind of stuff Rmus always wisely says. So, it shouldn't be a scary attack. :)

-{ Quote: "Yes I suppose that's what I meant haha. Exploiting the program that runs the file type. And the issue here is that you never know what programs are exploitable. Is the benign "Notepad" exploitable? Who knows haha. But it sounds like you're saying that it's impossible for a .txt file to contain exploited code which could attack your system via Notepad (unless you are incredibly silly and write yourself a "text editor" etc.)...right?" }-

Yes, it's difficult to know. But there are some good indicators of how likely a program is to contain vulnerabilities. Complicated software is generally more likely to have vulnerabilities than simple software (because it's easier to write 400 lines of perfect code than it is to write 4000), for example. And Notepad is very simple. Software that has been reviewed, used and examined for years and even decades is less likely to be vulnerable than new software that is just out of the code monkeys' keyboards - and so on. You could certainly put code that is designed to do nasty things in a text file. The problem is getting that code to execute when that text file is opened in a simple text editor like Notepad. Me? I can't remember there ever being a code execution vulnerability in Notepad. ;) While few things in the world are impossible, I'd be pretty surprised if someone got owned by a Notepad exploit these days. ;D

-{ Quote: "I don't quite understand why you mention social engineering attacks in the context of this discussion. If "trusted" software from a reputable developer/company has something malicious in it, nothing can save you from that (hence the importance of having a good back up system). It's just how far you want to take things. Recently I posted an analogy along the lines of: "if you go to the supermarket and buy milk, how can you be sure that it doesn't contain cyanide? Well, you'd hopefully go to a supermarket that's not owned by chemical terrorists etc. right?"" }-

Well, allow me to clarify. I mention social engineering because, as software security measures improve in an environment, attackers often turn more and more towards social engineering to own systems inside that environment - because social engineering is hard to prevent with software. So, I wasn't speaking of a reputable company shipping software infected with something bad. I was speaking of the way many users are far too quick to trust things, and that makes them vulnerable to social engineering. It's pretty unlikely that Microsoft would send you malware in automatic Windows Updates. But how about some random little software you find in P2P or on some website? How quick should one be to trust that?

Your analogy about poisoned milk is a good one. Most people buy milk from large markets that have been around for years and have a good reputation - and where there are people who are accountable if some of their products turn out to be bad. Most people wouldn't accept a bottle of alleged milk from some very shady looking, dirty kind of guy on the street that they've never seen that comes out of nowhere to offer it to them when they're not even out to buy milk. This, of course, in the real world. And that's the problem: in the computer world, people don't act like that. In the computer world, people do accept the milk from the dirty street guy, and gulp it right down without thinking, even if they weren't really looking for milk at that time. And then they fall down incapacitated by some drug and get... well, you know. Many people don't know who's shady and who isn't in the computer world, and that's why social engineering works so well. And it doesn't work only against newbies, because many rather advanced users are also far too quick to trust things. I bet someone could own a pretty decent number of systems just by advertising a new "anti-rootkit" on a security forum, and as the forumites download the "anti-rootkit" for testing and of course run it in a real system with admin rights because it won't work otherwise... ;D

[Windchild]

-{ Quote: "Hi Windchild,

what about that technique, I forget what it's called, maybe OLE or meta, something like that, where executable file types can be hidden within other, non-malicious file types such as .jpg?" }-

Basically, there are two possibilities:

The purpose of hiding an executable file inside a more innocent looking file can be simply to hide the executable file from prying eyes, in which case the idea is that the executable file should not under any circumstances be executed when you try to open the innocent file - otherwise, the hidden executable could be revealed, and if we're trying to hide it, we don't want that. Digital steganography, kind of: you hide your secret exe you don't want the admin to see inside a big image file. If the admin opens it, he sees a picture. You hope that he won't do any more thorough examination of the file. In this case, the executable file inside the innocent file is not a threat at all, in the sense that it could infect the system with something. It won't, since it can't execute. Creating for example image files with other hidden files inside is easy. But those hidden files won't be executed when you open the image.

The other possibility is that either by design or because of a vulnerability, some program that handles a given file type will try to execute the entire file or some piece of code the file may contain. It's no problem if it's supposed to work that way: .exe files being executed when the user double-clicks on them is of course like it should be. But this can be a problem if the execution is unexpected: if you can put code in a .PNG image file for example and that gets executed when you open the file in an image viewer because of a bug in the graphics rendering engine, then we have a security issue. Some vulnerabilities like this have been discovered and patched. Since such a vulnerability could be used to execute arbitrary code, it could be used for many kinds of nasty things including attempts to bypass something like SRP - limited only by the amount of code the vulnerability allows the attacker to execute. But as said, these are vulnerabilities, and when they get discovered, there's usually a rush to get a patch out and it will be fixed. I'm not aware of any vulnerability like this ever being discovered in Notepad. ;D And I don't seem to recall any case where you could just put a complete, normal executable file inside for example an image file and it would then get executed upon opening the image file. Typically it's just a small piece of code that could run.

So, there really isn't a way to execute code from "innocent" data files unless the program that handles those files is either designed to execute code inside the files or contains a vulnerability that makes it possible. That's why it's reasonable to differentiate between "data files" and "executables", even though it is true that anything could be executed if you simply feed it to some program that has been intentionally or accidentally made to do so. But to worry about text files containing malicious code? There is no realistic reason to worry about it. Start worrying when someone discovers an unpatched Notepad vulnerability that allows executing code from a malformed text file. But let's not hold our breaths while waiting for that day! ;D

[Kees1958]

-{ Quote: "
... not really a big deal attack in any way.... " }-

-{ Quote: "
... there are bigger fisk to fry ... " }-

Yep mainstream technology is still about data and processes. When developers stop dreaming about true OO-platforms and seamles processing clouds then it is time for system and security managers to get night mares on this topics.

-{ Quote: "
... unless the program that handles those files is either designed to execute code inside the files or contains a vulnerability that makes it possible... " }-

GeSWall and DefenseWall contain both threatgate applications and data (only formats with posisble code in it) so they allready provide containment for these future threats.

Regards Kees

[wat0114]

Windchild, thanks again as always for your awesome insight :thumb:

[Ilya Rabinovich]

Very old injection technique. Not interesting.

[Longboard]

-{ Quote: "Very old injection technique. Not interesting." }-
Outstanding post.
Thankyou.

[Windchild]

-{ Quote: "Very old injection technique. Not interesting." }-

Well, that's a very good way to summarize it. :thumb:

If I could write posts like that, I'd have much more time for Scotch. ;D

If there's something interesting about the technique, then it's that it shows a valid way to bypass even a very tight SRP. IOW, it does show that while SRP is very handy, it's not 100 % as they say. ;D

[Ilya Rabinovich]

-{ Quote: "What do you find genuinely "interesting" in the world of computer security and exploits to bypass specific setups then?" }-
Unusual usage of standard API or discovering rare mentioned API's/APIs control codes.

As about SRP bypass- I don't care as its MS head ache, not mine, DW is invulnerable to it.

And yes, WriteProcessMemory/CreateRemoteThread it's quite "boring" way to bypass anything. Maybe, working, but boring anyway.

[Hugger]

-{ Quote: "Very old injection technique. Not interesting." }-

OK tiger, that's enough strenuous work for now.
Nap time.
Hugger

[Longboard]

-{ Quote: "If I could write posts like that, I'd have much more time for Scotch. " }-:o Another outstanding post ;D

[Windchild]

-{ Quote: "Didn't realise it was an "injection technique"? Windchild, would you care to explain a bit more? I'm a bit dull when it comes to these things. Cheers mate." }-

Like Ilya said and Didier showed in his blog entry: the macro uses WriteProcessMemory and CreateRemoteThread functions to write code into a process and then execute the code, and this code then patches SRP checking that is done inside the process off, allowing you to bypass SRP. This is an injection technique because the macro injects some code to a process and gets it executed in that process. The process has to be one the user has write access to, of course: in LUA, the macro could inject its code into Excel.exe running in the limited user account or explorer.exe for example, but could not inject code into processes running with higher privileges like an svchost.exe instance running as SYSTEM. It's not DLL injection since there's no DLL, but it's code injection still.

-{ Quote: "What do you find genuinely "interesting" in the world of computer security and exploits to bypass specific setups then?" }-

Attacks that are both new and do not require massive user stupidity to work are interesting to me. But if it's just the same old thing used to do something a little different than before, it doesn't really interest me.

To give an example of the uninteresting, the whole MBR rootkit thing was very uninteresting to me because MBR infections were nothing new, they were done already in the DOS age, and because it required the user to be admin to work. Boring...

Of course, when I say it's not interesting to me, I don't mean that it's something people shouldn't talk about. As you said, "interesting" really is relative. Attacks like this are very much worth talking about, since most people aren't aware of them or understand them. But perspective is important: this isn't really a new attack, and there are many ways to prevent it and limit its impact. Ilya mentioned DefenseWall, for example, and sandboxing and virtualization in general will work, as will any classic-style HIPS product that watches for CreateRemoteThread etc. And even just a simple limited user account will limit what it can do: no system-wide infection.

But certainly, when I have to choose which is more interesting to me, a thread about an attack technique (no matter how old) or a thread about AV test number 193878535325098 then I'll go with the former any time of the day. ;D

[Kees1958]

-{ Quote: "Sounds good Windchild. LUA is definitely the way to go. I can't believe how perfectly it combines with SRP and Sandboxie. It makes me feel that Tzuk created Sandboxie to be used specifically in LUA haha." }-

Nahh, MS developed Steady State to be used in conjunction with to LUA

Good you found value in available mechanismes to reduce the attack surface with LUA/UAC and SRP, pity you keep on telling everybody that LUA is stronger than DW.

Regards Kees ;)

[BlueZannetti]

-{ Quote: "...pity you keep on telling everybody that LUA is stronger than DW." }-This is one of those topics that can be argued from either side of the aisle. In a sense LUA is stronger than DW, and in other aspects DW is more powerful than LUA.

The power of LUA - you don't make decisions. The account is set to LUA and you are done.

The power of DW - you have flexibility, but with flexibility comes responsibility. You need to make decisions at some point. In some contexts this is power, in others it is a liability. It depends who's at the keyboard.

In a sense, mating LUA with SuRun is intermediate ground. Added flexibility to navigate through legacy issues, added responsibility to make the right call if you decide to pull Admin privileges.

Blue

[Scoobs72]

-{ Quote: "

In a sense, mating LUA with SuRun is intermediate ground. Added flexibility to navigate through legacy issues, added responsibility to make the right call if you decide to pull Admin privileges.
" }-

From my simplistic understanding, the whole point of LUA was to take away capabilities from users who can't be trusted so they can't do things to a PC that the admin doesn't want them to do. It's not suitable in it's pure form for users who do/should know better, which is why you have to add SuRun back in to give back some of which you have taken away. I think my viewpoint is that if you are going to 'give back' then you're much better adding in proper flexibility with DW, which at the same time gives stronger than LUA protection, rather than trying to frig LUA in a way it wasn't intended.
Also, the beauty of DW is that the flexibility is there only if you want it. DW runs fine on my wife's PC without her even being aware of it. No flexibility is required.

So on all counts it is difficult for me to see any scenario where LUA is more powerful than DW. Just MHO.

[BlueZannetti]

-{ Quote: "From my simplistic understanding, the whole point of LUA was to take away capabilities from users who can't be trusted so they can't do things to a PC that the admin doesn't want them to do." }-That's really the wrong way to view it. That brands LUA as punishment of some sort.

Daily PC usage should not require Admin level access. Routine usage does not involve the installation of new applications, system level configuration, and so on. Routine usage is running the applications that have been installed on the PC. This shouldn't require admin level access.

The point is not to "take away capabilities from users who can't be trusted", it is to grant only those capabilities required, when they are required.

If you're performing an Admin level task (say installation of a new application), then get the privileges needed for that task, but don't retain them when you step back into daily work mode.
-{ Quote: "It's not suitable in it's pure form for users who do/should know better, which is why you have to add SuRun back in to give back some of which you have taken away." }-No..., SuRun is a convenience. It allow temporary escalation of privileges for a specific task within a session as opposed to retaining that level of access for a whole session. You are really viewing this from the wrong perspective.
-{ Quote: "I think my viewpoint is that if you are going to 'give back' then you're much better adding in proper flexibility with DW, which at the same time gives stronger than LUA protection, rather than trying to frig LUA in a way it wasn't intended.
Also, the beauty of DW is that the flexibility is there only if you want it. DW runs fine on my wife's PC without her even being aware of it. No flexibility is required.

So on all counts it is difficult for me to see any scenario where LUA is more powerful than DW. Just MHO." }-Once everything is properly vetted and configured, you might be right. They might be equivalent, which arguably makes a case that DW is more "powerful". The point that I'm making is that creating a situation or basing a security strategy on a scenario that requires a user to make decisions on-the-fly is, IMHO, a fundamentally flawed approach for a typical user.

Blue

[Scoobs72]

-{ Quote: "That's really the wrong way to view it. That brands LUA as punishment of some sort.

" }-

I did say it was my simplistic viewpoint :) Seriously though, whilst most sys admins may hold your viewpoint, I think most computer users who have LUA imposed upon them in a corporate environment would view the reason as one of trust. A quick poll round the office has confirmed that.

[wat0114]

-{ Quote: " It's not suitable in it's pure form for users who do/should know better, which is why you have to add SuRun back in to give back some of which you have taken away. " }-

I disagree. i do know better and i'm 100% confident i can stay uninfected as admin but I can do everything i need to do as lua, so why not? When i need to make admin-like changes, it is very simple for me to log in as such temporarily for those changes. I run primarily as lua simply because it is far more secure than admin.


-{ Quote: "I think most computer users who have LUA imposed upon them in a corporate environment would view the reason as one of trust. " }-

Of course! although there are some responsible people working in a corporate environment, there are also idiots who in no time will perpetrate viruses all over the LAN due to their surfing pron and installing cracks and keygens if they are given admin privs.

[Scoobs72]

Whilst we are all coming at the LUA subject from different angles the original point I responded to was the relative strength of LUA versus DW and subsequently their relative flexibility. I maintain that DW is a stronger/more flexible solution than LUA that has the same benefit of being able to be used in a zero user interaction environment....for users that can't be trusted :) Comments like "LUA is definitely the way to go" need to be balanced and put into context with the alternative solutions available.

[Kees1958]

-{ Quote: "From my simplistic understanding, the whole point of LUA was to take away capabilities from users who can't be trusted so they can't do things to a PC that the admin doesn't want them to do. It's not suitable in it's pure form for users who own the PC, they also want to be boss of the PC, therefore want to run ADMIN, which is why you have to add SuRun back in to give back some of which you have taken away. True, Microsoft admitted this by providing UAC on VISTA and UAC on a sliding scale with Win7 I think my viewpoint is that if you are going to 'give back' then you're much better adding in proper flexibility with DW, which at the same time gives stronger than LUA protection, rather than trying to frig LUA in a way it wasn't intended.
Also, the beauty of DW is that the flexibility is there only if you want it. DW runs fine on my wife's PC without her even being aware of it. No flexibility is required.

So on all counts it is difficult for me to see any scenario where LUA is more powerful than DW. Just MHO." }-

Same here and I know this is also valid for Jmonge, my wife does not know it is there, with the whitelist option in V3, even more decisions can be taken away from the average user

Only in red my slightly different opinion.

As said I am happy with UAC/Norton's UAC tool on Vista and with UAC on Win7, combine it with Sully's PGS to achieve SRP and you have reduced the attack surface in a flexible way.

[Kees1958]

-{ Quote: "
No..., SuRun is a convenience. It allow temporary escalation of privileges for a specific task within a session as opposed to retaining that level of access for a whole session.

Blue" }-

Surun is UAC on XP, it gives the convienance of not switching to another user.

Blue, so it offers flexibility, the same as when I decide to run something different with DW. That is the same flexibility mechanism.

So I can't follow you arguments

A) DW is weaker because it is flexible

b) Surun is strong becasue it offers convienant flexibility

Help :argh:

[andyman35]

-{ Quote: "[COLOR="Blue"]

[B]As said I am happy with UAC/Norton's UAC tool on Vista and with UAC on Win7, combine it with Sully's PGS to achieve SRP and you have reduced the attack surface in a flexible way." }-
Me too ;D

[Scoobs72]

-{ Quote: "I think all Blue was trying to say is that whenever any "decision-making" is involved, it could be a problem, whether it's decisions on when to use SuRun or when to run applications as "trusted" with DW." }-

But one of the key points for me is that you normally don't have to run applications as trusted with DW. So you can often install software as untrusted whilst still keeping the software contained in a stronger than LUA environment. Therefore you take away any decision making, eliminating one further weakness.

[Scoobs72]

-{ Quote: "With this in mind, I don't see the point of using third party software that provides a similar concept of protection to a simple windows "tweak".
" }-

I think with that comment you show that you don't really understand DW.

[Scoobs72]

-{ Quote: "If you are unsure whether you can trust a piece of software, you should not be installing/running it on your REAL system. " }-

That's not how 99% of normal users operate. That's why so many people get hit by malware. Fine for most people on Wilders, but not for the rest of the population.

-{ Quote: " I'm noticing a lot of people say that their Windows slows down over time and installing/uninstalling software in this way could contribute to this." }-

I don't really understand the relevance of that.

[demoneye]

-{ Quote: "I think with that comment you show that you don't really understand DW." }-

i think we are talking on 2 diffrent ways of protection , one is for advanced users and its sj100 way , and the sec is DW who belong to new pc users or lets call them noobs :)

both method works, depending on your skill of understanding what is going on behind the scene , and according to that you select the more suitable way for you

cheers :)

[Windchild]

There's really not too much point in arguing whether (some security software) or LUA is stronger.

Some classic HIPS or something like DefenseWall offers very granular control over things that are far beyond the intended scope of different types of user accounts in modern multi-user operating systems. They can do things LUA was never intended to do. In that sense, they're certainly undeniably stronger as malware protection.

LUA is not intended to be comprehensive malware protection or anything like that - it's just access control that naturally also limits the access malicious software could have. In that role it's very useful, and indeed should be a key part in most any security policy. It doesn't cost extra, and you don't need to install new versions of it. It can often help security software be more effective against threats, even when the security software has an unpatched vulnerability or a design defect that could be exploited by a malware. And it does do some things that few HIPS-like products do, like controlling what files and folders the user can access - handy stuff when you don't want the kids deleting all your files, for example. If one wishes to compare strengths, then LUA's strength is that it's free, far less intrusive than most security software, doesn't cause slowdown or kernel stability issues that you wouldn't otherwise have and doesn't present the user with complex choices: the only thing the user might get asked about in LUA is "Do you want to run this as admin, yes or no?"

So, really, the well-informed LUA advocate obviously won't claim that LUA by itself somehow provides the best security possible with software. Instead the claim is that LUA is an essential basis to build security on, and if one is so inclined, is pretty effective against many things even all by itself, and very effective if the user knows what he's doing. This can allow some users to run a much lighter and cheaper setup without unreasonable risk, for example. But perhaps the best reason to use LUA is because it's there. Why make things easy for the bad guys? LUA makes it harder to own systems completely. Why shouldn't people use it, especially the kind of people who aren't very advanced with computer security, when it's free and won't slow your system down or make it crash? For those people who would normally only run an AV while being admin, going to running AV with LUA would be a massive increase in security, and would benefit everyone online. To not advocate that would be idiotic.

[BlueZannetti]

-{ Quote: "Seriously though, whilst most sys admins may hold your viewpoint, I think most computer users who have LUA imposed upon them in a corporate environment would view the reason as one of trust. A quick poll round the office has confirmed that." }-Well..., I don't work in a field even remotely related to IT, and have my share of complaints with the IT dept of my employer,... but the IT folks have a point if operational stability is a goal and it generally is.

Blue

[BlueZannetti]

-{ Quote: "I think all Blue was trying to say is that whenever any "decision-making" is involved, it could be a problem, whether it's decisions on when to use SuRun or when to run applications as "trusted" with DW." }-It's less making decisions per se and more making those decisions on-the-fly. After all, any approach requires decisions to be taken at some point in time.

Blue

[Kees1958]

-{ Quote: "Sounds good.

However, in my opinion, that is not a very good "security approach". If you are unsure whether you can trust a piece of software, you should not be installing/running it on your REAL system. Furthermore, I don't think you can know for sure whether the software will install properly as "untrusted" with DefenseWall. I'm noticing a lot of people say that their Windows slows down over time and installing/uninstalling software in this way could contribute to this." }-

Software which requires admin rights, simply fails when installed as untrusted.

You have no idea how DW works, so what is the point of replying I ask myself.

As stated earlier: on our Vistax64 the security is formed by UAC - Norton UAC control, Software restriction Policies thriugh Sully's PGS (deny execute user space, LUA of all internet facing aps, excluding IE8, since it starts with lowes rights = protected mode) and MSE.

With the added security/contingency features of Vistax64 (over XP f.i.), I am sure this is a pretty solid set up. UAC/SRP is good prevention.

[Kees1958]

-{ Quote: "That is a very arrogant reply, in my opinion (and you seem to have taken a rather bitter attitude towards me...for example, you thanked Windchild for apparently "scaring" me the other day...then you came up with a SRP bypass that wasn't a bypass at all - that was a bit confusing for me for a while...usually you clear things up, not make things more confusing...). If you think I am wrong or mis-guided, why don't you at least try to educate me haha.

Please tell me what I don't understand about DefenseWall.

Going back to my point, how can you tell if software will install properly as "untrusted" with DefenseWall? I can't tell. And I'm not the "average user". Can your wife tell for instance?" }-

SSJ,

We have a history of teasing/challenging each other. Consider it a tease gone bad. I do not want to sound arrogant, neither am I bitter towards you. Something is lost in translation, my sincere apologiies


With DW v3 it is quite simple for my wife.

I have password protected DW's setting.

With DW3 you can tell DW to use a whitelist, when you apply the white list, you can choose on which threatgates it is valid. So when she installs from a USB drive, one of the browser download area's AND it is white listed, DW automatically allows the install as it was a trusted object.

All other installs will fail when the install needs admin priveledges. In daily practise a failed install will revert the installation process (at least this is what always happened in our experience - I can check this using the logs/roll back list). When you want to allow such an install, you have to manually set this object to trusted. This requires a password (same as run Admin would do).

So she even gets less error messages than running LUA (in which whitelisted installs needing admin rights would also fail with a message).

Also DefenseWall is the most quiet HIPS and FW available on the market to my knowledge (the white list is also used for outbound traffic when you choose to apply it).

So using arguments like granular control and flexibility ONLY applies to DefenceWall when you are a fanatic user of the resource protection feature of DW and have set resource protection notifications on (otherwise the user will be silently protected).

Also Ilya has implemented a lot of my resource protection features out of the box (e.g. denying other untrusted programs access to you web address book or email folders).

There is currently only Resource Protection rule which I use extra (compared to the out of the box setting f DW). Maybe you remember the bufferzone trojan test. The trojan thinks there are no files in My documents, because resource protection prevents it from reading my Documents.

You can consider resource protection of DW as advanced ACL on steroids, same as DW itself can be considered as a SRP as basic user on steroids.

So we are not having a disagreement on the benefits of policy management. As said on x64 I am quite happy with UAC + SRP (when GeSWall will be available on x64, I will gladly add this to the setup and remove ThreatFire).

Again: sorry for the tone of voice in the posts

Regards Kees

[Kees1958]

-{ Quote: "Well..., I don't work in a field even remotely related to IT, and have my share of complaints with the IT dept of my employer,... but the IT folks have a point if operational stability is a goal and it generally is.

Blue" }-


True,

Stability (up time), cost and legal.

Standardisation reduces cost, LUA is a form to increase standardisation

There is also a legal aspect. In some countries you can only claim damage when the person inflicting the damage could assume in all reason that his actions would cause damage. Because computer security is such a grey area, judges sometimes check whether the company acted as a 'governing parent' to prevent the employee from making stupid mistakes (or at least bring hiim/her not in the cicumstance to make mistakes). Because security is such a grey issue and related issues like privacy and non-disclosure sensity data are so complex by thereselves, it is best practise to setup all employees as LUA (in most European Union countries).