Is Limited User Account enough? Not really...

[thanatos_theos]

{QUOTE-> I often read on online boards how many people are saying that using a Least-Privilege User Account (or Limited User Account, LUA) can prevent you from being infected by any kind of malware.

While this is a true statement and, indeed, this should be the way to go for a number of reasons which I'll explain a bit later, the truth is that using a Limited User Account doesn't save you from every kind of infection. <-QUOTE}
Full Article (http://www.prevx.com/blog/83/Is-Limited-User-Account-enough-Not-really.html)

thanatos

[SystemJunkie]

Absolutely my opinion, all those LUA junkies are on the wrong path and far away from reality.;D ;D ;D

[Mrkvonic]

Hello,

Any article from a security software vendor explaining why XYZ is not good enough, when XYZ is usually free / alternative / non-conventional way of preventing and containing software infections is flawed by definition.

Like asking an arms salesman should you buy a gun - or a banker, should you take a mortgage...

Throwing in big words helps - user mode, DCOM etc ...

In fact, it all comes down to the kerneld module and kernel hacking mode.

If kernel hacking mode is enabled, you might get hacked. Example:

And if some user space memory is allocated using kmalloc with GFP_USER flag and then passed to map_user_kiobuf, trying to simulate what it does when user memory is passed to it on directIO user space write calls, it will fail with EFAULT (Bad address).

If malicious code is transferred then you might get memory overflow. And kerneld will dynamically load bad modules, compromising the system.

You see? I don't.

Mrk

[lucas1985]

Marco Giuliani's article is correct, even if it's a bit biased (he works for a security provider)
Important statements:
{QUOTE-> Having administrator privileges, you can do what you want, even going in-depth to manipulate the system core. Most of the current kernel-mode rootkits can do their dirty jobs because they have administrator privileges. <-QUOTE}
{QUOTE->
The way that Windows (starting from NT to Vista and excluding all Windows 9x versions that were based on another kind of kernel) handles user privileges is quite strong and, at the moment, there aren't any known ways to manipulate it unless you already have administrator privileges and, therefore, you can compromise the whole system (or if there's an unknown bug on some Windows core component or on some software already running with full privileges that would enable privilege escalation, but this is another interesting story).
<-QUOTE}
{QUOTE->
Using a limited user account, we can indeed have a high level of security. Let's see a basic example: most types of malware try to write a copy of their code into the Windows or Windows system directory, and try to get startup permissions by adding registry keys under HKEY_LOCAL_MACHINE Windows registry subtree, that contain information about the local computer system. This key is common to every user created on that machine, this would mean that the infection will be active anyway, no matter which user starts the machine.

A piece of malware running under a standard limited user account couldn't write into the Windows or Windows system directories, or write into that part of the Windows registry. A kernel mode rootkit (Rustock, Bagle rootkit, Srizbi, part of Haxdoor, and others) would need to load into kernel space its own driver. There are several ways, documented and undocumented ones, but every one needs administrator privileges. These are just some examples to explain that running under a limited user account would really prevent you from a lot of current infections.
<-QUOTE}
{QUOTE->
I'm sure someone is already thinking: "Sure, it is possible, but these rootkits can be easily detected and removed. It's enough that an antimalware software is running under Administrator or SYSTEM account so that it can't be corrupted by the rootkit, because a limited user account can't access to other processes he owns".
<-QUOTE}

The author acknowledges that if malware is executed under LUA it can't tamper the kernel/OS core (excepting from privilege escalation vulnerabilities on applications running with admin privileges). What does that mean to you? It means that you can trust your security tools (because the OS isn't subverted) and that easy recovery/cleaning is almost guaranteed.
In other words, LUA is like a "poor man's sandbox", keeping the OS core safe from malware attacks.

{QUOTE->
Is the LUA enough?

No, it isn't, at least in its standard configuration.
Let's think: one of the goals of current malware is to steal user information so that they can be sold on the underground market. This dirty job can be done even from a guest account; even from there it is possible to intercept and log keystrokes. Then it can still find a way to run at Windows startup - yes, if it isn't possible to write into HKLM, it's still possible to write into your own HKEY_CURRENT_USER key registry subtree.

This means that the malware will run only when the infected account logs on: is this a problem? Not at all for a malware writer: the goal is to infect and steal information, and this is what is done.

We can then go on to talk about rootkits. I've already written above that under a limited user account, a kernel mode rootkit can't run; but don't forget about user mode rootkits.
<-QUOTE}
Correct, malware can and will execute under LUA in its standard configuration and it will survive reboots (automatic launching) because it has write permissions to some autostart entries. Not a big deal really:
- Disable (http://www.wilderssecurity.com/showpost.php?p=1156834&postcount=25) the few remaining autostart points with write permissions. If you do this trick, no malware will launch automagically.
- Restrict (http://www.mechbgon.com/srp/) execution permissions to Program Files and WinDir (in standard configurations). If you do this trick, the only writable folder in LUA (USER) won't have execution permissions. Malware will be written to this folder, but it won't execute.
198517

{QUOTE->
Yes, they (malware which work fine in LUA) can be defeated in an easier way, but we need a security product to do it. And the people who usually think that a standard limited user account is enough to avoid getting infected, won't care to check if they're infected.

The truth is that, even under a standard limited user account, there are still several ways a piece of malware can infect a pc. I have only talked about some ways malware can work, but there are still other ones I won't talk about.
<-QUOTE}

Here, Marco starts to lose accuracy. Sure, we will need security software (the free Prevx CSI is perhaps one of the best tools for people running LUA + SRP), but their role is secundary at best. And people running LUA, LUA + SRP or other "non-standard" security setups (non-standard = setups based on whitelisting, default-deny principles and so on) usually care to check their system for infections with on-demand scanners (web-based, self-contained apps or installed AVs like Prevx CSI, Dr. Web CureIt, the numerous web scanners, free AVs, etc), rootkit scanning, integrity checking (RunScanner, Autoruns, apps which build a database of hashes, system logs, etc) and such.

I'm disappointed that Marco won't talk about some malware which work in LUA. Perhaps he can change his mind and clarify that for us.

[EraserHW]

{QUOTE->
I'm disappointed that Marco won't talk about some malware which work in LUA. Perhaps he can change his mind and clarify that for us. <-QUOTE}

As shown in the video, Vanquish is just one of many user mode rootkits that can work under standard LUA and accounts under UAC

[lucas1985]

Hi Marco,
Great to see you here. A little question: how will Vanquish execute if a SRP is in place?
I would be more than happy if someone can show me malware which manages to execute under LUA + SRP without user intervention (i.e. convince the user to give admin credentials like the Mac Zlob or installing trusted software which became infected somehow)

[EraserHW]

Hi,

it depends on what rules have you set up on your restriction policies. Moreover, don't forget that cutting out user's interaction you're cutting out a big percentual of actual malwares.

Yet, you could even set up total Windows lockdown forsure, but remember that it will be a complex solution for the biggest part of people out there.
If they start having troubles even installing softwares, think that they won't wonder so much if they need to install latest "codec" to watch porn movies (i.e. trojan downloader) or not. They'll do it.

[lucas1985]

{QUOTE->
it depends on what rules have you set up on your restriction policies. Moreover, don't forget that cutting out user's interaction you're cutting out a big percentual of actual malwares. <-QUOTE}
Good to know. I will continue looking for holes in LUA + SRP. I also disable autorun globally and only install trustworthy software from trustworthy sites (http://www.wilderssecurity.com/showpost.php?p=1202667&postcount=22)
{QUOTE-> Common sense (download from author's website, do a research before installing, gather users' opinions, etc), Virustotal/Jotti, online sandbox (Norman Sandbox, Sunbelt Sandbox, ThreatExpert, Anubis, etc), checking of hashes/digital signatures (if available), running in a VM first, EULAlyzer, etc. <-QUOTE}
DEP is set to OptiOut (some software don't work properly with AlwaysOn) and a two-way firewall enforces a strict network access policy. Finally, I use Firefox + NoScript to browse the web. NoScript allows me to control the load/execution of plug-ins (Quick Time, Java, Flash, etc) and I reject IFRAMES and suspicious scripts (excesively long scripts, lots of random characters) which look obfuscated to my (untrained) eyes.
{QUOTE-> Yet, you could even set up total Windows lockdown forsure, but remember that it will be a complex solution for the biggest part of people out there. <-QUOTE}
It's a perfect solution for people running "static" machines. Format, install Windows, install/update software/drivers/patches, configure/tweak settings, build a security policy (LUA + SRP + ICF + security app + ad-blocking app), defrag and take an image. You can teach people that they all the necessary codecs are already installed (a good codec pack). LUA + SRP is certainly a bad solution for "dynamic" machines, when users are installing software all the time (so they will be granting admin rights everytime)
{QUOTE-> If they start having troubles even installing softwares, think that they won't wonder so much if they need to install latest "codec" to watch porn movies (i.e. trojan downloader) or not. They'll do it. <-QUOTE}
So, do you agree that remote code execution is becoming less of an issue and that social engineering is the main avenue for infection?

[wat0114]

My "broken record" rant: I can't talk about Vista because I've never used it, so no comments. Regarding XP or W2K running under an all-out SRP/LUA/limited policy, whatever you want to call it.... is a big joke. I don't know half of what lucas, Mrkvonic or many others in this forum know on a technical level, but I do know what these "nanny state" accounts can do to an individual's user experience on these pcs. They cause never-ending grief because some programs don't function properly, freeze, error messages abound, reboots are needed frequently...etc.

These restrictions are done in a corporate environment probably out of necessity because it is impossible to teach everyone to use a computer responsibly and the big business can't take any chances, so I understand that. On a home pc, however, it is overkill. On my pcs I have partial limitations set to key directories, enough to keep things relatively safe without causing functionality issues. The rest is done by a couple security apps, fully patched O/S and common sense. Anyone worrying about what their kids may do should simply take the time to teach them, rather than taking the easy, but knee-jerk approach of just locking them out of everything.

[zopzop]

{QUOTE-> - Disable the few remaining autostart points with write permissions. If you do this trick, no malware will launch automagically. <-QUOTE}

is there anyway to do this without having to use SuRun? like using SRP?

[lucas1985]

{QUOTE-> I don't know half of what lucas, Mrkvonic or many others in this forum know on a technical level <-QUOTE}
I know very little, but I'm always learning.
{QUOTE-> They cause never-ending grief because some programs don't function properly, freeze, error messages abound, reboots are needed frequently...etc. <-QUOTE}
- Choose software which is "LUA-friendly".
- Tweak the permissions (requires expertise with FileMon/RegMon)
- Give admin privileges to problematic software.
{QUOTE-> is there anyway to do this without having to use SuRun? like using SRP? <-QUOTE}
Not sure, I'm still very new to LUA/SRP, but what's wrong with using SuRun?

[zopzop]

{QUOTE->
Not sure, I'm still very new to LUA/SRP, but what's wrong with using SuRun? <-QUOTE}

it seems very complicated. i'm a simple man :)

[wat0114]

{QUOTE-> I know very little, but I'm always learning.
<-QUOTE}

Well, you are being modest ;)

My only problem with LUA/SRP is the [u]extent[/i] to which I have seen it taken, whereby it is so incredibly restrictive that it causes the problems I mentioned above, in other words all out restrictions imposed by the security template. I use it on my home machines to a lesser extent and it works very well without interfering with my day-to-day tasks.

[zopzop]

i have a quick question, in this post here :
http://www.wilderssecurity.com/showpost.php?p=1156834&postcount=25

tlu lists 7 autostart locations that are allowed right access in a LUA :

{QUOTE->
* c:\documents and settings\<user>\start\program files\autostart
* c:\documents and settings\all users\start\program files\autostart
* HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
* HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
* HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
* HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
* HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows <-QUOTE}

where the heck are the ones i bolded located on the computer? i have windows xp media center edition with SP2 and i can't find them on my pc.

like i can follow it up to c:\documents and settings\all users (or "user")\

then that's it. i don't see "start" i see "start menu". also i don't see "program files" i see "programs" and i don't see "autostart" i see "startup".

what i'm asking is, is this :
c:\documents and settings\all users\start\program files\autostart

the same as this :
C:\Documents and Settings\All Users\Start Menu\Programs\Startup

[Cerxes]

@zopzop: It´s your autostartfolder, which you normally access from "Start" (or the startmenu). Depending on the language of your OS the folders can have similar names such as "Program" instead of "Program files" etc. Instead of locking down those autostart entries, I would advice using a reg. monitor application such as Winpooch or RegDefend for monitoring those entries so it could be more convenient when you for example want to change some application settings that you use in your restricted account.

/C.

[kareldjag]

Hi,

This is here a marketing paper to promote PrevX.
In this case i'd rather the Symantec's one, much more interesting and less vague:

www.symantec.com/avcenter/reference/Impact_of_Malicious_Code_on_Vista.pdf

In fact there's a diiference between the OS as it comes (XP or Vista), and a deeply hardened system.
By deeply hardening Windows (system file permission, locking the registry, using a white list approach for application like "default-deny (http://www.windowsecurity.com/articles/Default-Deny-All-Applications-Part1.html) rule" etc), the risk is very limited.
Even under an admin. account, it's not diificul to prevent kernel level malwares (www.f-secure.com/weblog/archives/kasslin_AVAR2006_KernelMalware_slides.pdf)

I've wrote an article (http://kareldjag.over-blog.com/article-6649283.html) in the past which provides various info in relation to Windows hardening (the Pedestal (http://www.pedestalsoftware.com/products/se/downloads/webscan/)test is interesting to do).

By a high level of OS hardening, we create a kind of sandbox environment (but as there's no OS isolation, it's not a Sandbox) which mitigate impact of attacks and intrusions (hackers, malwares).

PrevX is a good product, but i've never appreciated their Bling-Bling marketing (the test on the web site for instance is fully corrupted: PrevX is an HIPS Suite that should be tested with other HIPS Suite like OA +AV, SafenSec + AV or KAV 7 and not with pure black list scenner engines).

Regards.

[zopzop]

{QUOTE->
If you do this trick, the only writable folder in LUA (USER) won't have execution permissions. <-QUOTE}

see this statement scares me. in my LUA (in windows xp media center edition sp2) i CAN write to other folders on my drive, not just my "user" aka "limited" folder. i can write to my c:\temp, c:\xnews, etc... the only folders i can't write to are c:\programs and c:\windows.

can anyone explain this discrepancy?

[SystemJunkie]

{QUOTE-> Good to know. I will continue looking for holes in LUA + SRP. I also disable autorun globally and only install trustworthy software from trustworthy sites <-QUOTE}You are really incredible paranoid... but do you think your protection will work against Stealth.MBR? (assumed you use Windows XP, Vbootkit for Vista) It only creates some tmps in user temp, nothing else. No autostart, no keys, no files.
You can´t lock temporary directory ;D;D;D.
And think about a combination of the best user mode rootkits + stealth mbr or bios rootkit (more sophisticated ones)...
They could put your account in a box and you´d think you are safe. ;D
Do you think script block is enough? Are there no other vulnerabilities in browsers?
Ever heard from general smb problem? Think about a malware that melts unix and windows access.
They patch your files before windows is installed... lots fun with your restricted user account. ;D;D;D
I don´t know if you heard about manufacturer stories from asia... they implemented already malware
by default in hardware. Can you trust hardware from China? In relation to this your whole LUA work could be in vain. ;D;D;D But let´s hope such extreme thoughts or realities won´t be too widespreaded.

[solcroft]

{QUOTE-> but I do know what these "nanny state" accounts can do to an individual's user experience on these pcs. They cause never-ending grief because some programs don't function properly, freeze, error messages abound, reboots are needed frequently...etc. <-QUOTE}
Facts and evidence, please, instead of vague FUD.

I have used a Limited User Account for the better part of half a year. I have not experienced the symptoms you describe. Please stop scaring people off from a very effective and credible solution by trying to pass off your unfounded, untested and utterly false preconceptions as fact.

[solcroft]

{QUOTE-> You are really incredible paranoid... but do you think your protection will work against Stealth.MBR? <-QUOTE}
SystemJunkie, there is no other way to accurately describe you other than Wilders' biggest FUD machine. You constantly post misleading mumbo-jumbo that are entirely baseless, substanceless, and purposeless other than to sate your fervent belief than invisible little green men control all our computers. This has got to stop.

To answer your question, a Limited User Account blocks write access to the MBR. So no, your precious Steal.MBR is completely castrated here.

[LoneWolf]

Sorry to butt in.

FUD ???

[solcroft]

{QUOTE-> Sorry to butt in.

FUD ??? <-QUOTE}
Precisely.

I'm fully willing to debate this issue so that some real facts can see the light of day instead of a load of baseless allegations, and I dare them to give a reasonably cohesive explanation of their claims.

[LoneWolf]

{QUOTE-> Precisely.

I'm fully willing to debate this issue so that some real facts can see the light of day instead of a load of baseless allegations, and I dare them to give a reasonably cohesive explanation of their claims. <-QUOTE}

Ok, I agree with this.

But what does FUD stand for ???

[solcroft]

A good rule of thumb is Wikipedia + Google before asking.

http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt

[LoneWolf]

{QUOTE-> A good rule of thumb is Wikipedia + Google before asking.

http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt <-QUOTE}

Sorry for asking. ::)
But thanks. ;D

[BlueZannetti]

{QUOTE-> I'm fully willing to debate this issue so that some real facts can see the light of day instead of a load of baseless allegations, and I dare them to give a reasonably cohesive explanation of their claims. <-QUOTE}Just a reminder to all and to emphasize what is already stated - use real facts - not random screenshots that have no context and ill-defined parentage and meaning, meaningless technobabble, and/or logistically outlandish scenarios. Focus on genuine technical points, not the personalities involved.

On the general question, security discussions in any context (PC, personal, home, etc.) and at any location do seem to generate a high level of FUD. As always, caveat emptor.

Blue

[SystemJunkie]

Solcroft at least we all know now what the meaning of FUD really is.;D;D

[lucas1985]

{QUOTE-> see this statement scares me. in my LUA (in windows xp media center edition sp2) i CAN write to other folders on my drive, not just my "user" aka "limited" folder. i can write to my c:\temp, c:\xnews, etc... the only folders i can't write to are c:\programs and c:\windows.

can anyone explain this discrepancy? <-QUOTE}
Mmmm, are you listed as the owner of those folders? See here (http://www.wilderssecurity.com/showpost.php?p=1201866&postcount=146) for more in-depth details.

[zopzop]

{QUOTE-> Mmmm, are you listed as the owner of those folders? See here (http://www.wilderssecurity.com/showpost.php?p=1201866&postcount=146) for more in-depth details. <-QUOTE}

thx for the link lucas. i went over there followed the instructions and did a quick dir /q. even though everything comes up as being owned by the "built in administrator" when i log on my limited user account, i can still write to c:\temp, c:\xnews, etc...

[lucas1985]

How did you create your limited account? Is it a new account or it was previously an admin account?
Is explorer.exe running with limited privileges?
Try AccessEnum.

[zopzop]

{QUOTE-> How did you create your limited account? Is it a new account or it was previously an admin account? <-QUOTE}

i'm 100% sure it was created as a limited account (not as an admin account made limited).

{QUOTE-> Is explorer.exe running with limited privileges? <-QUOTE}

in my limited user account? or in my admin account? and how would i check?

{QUOTE-> Try AccessEnum. <-QUOTE}

i just downloaded and ran it. it has the following sections : path, read, write, deny. for example my c:\temp, has read : administrator, users. write : administrators, users.

EDIT :

ah ha! after messing around with AccessEnum and seeing just how much folders had write access : administrators, users and going into a panic :D i messed around with the "security" tab located in the folder property option. it seems there was a whole group of "users" that had "special permissions" with the following options enabled : files/folders with create folders/append enabled. and another entry for "users" that had "special permissions" with the following options enabled : subfolders with create files/append enabled. i disabled each and then tested again. lo and behold, i CANNOT create files or folders anywhere except my desktop in my limited user accounts!

now i have to do this on my desktop and my brother and sister in laws pcs. quick question : how the heck did this happen?

[The Hammer]

{QUOTE-> Ok, I agree with this.

But what does FUD stand for ??? <-QUOTE}http://www.urbandictionary.com/define.php?term=FUD

[lucas1985]

{QUOTE-> i'm 100% sure it was created as a limited account (not as an admin account made limited). <-QUOTE}
I've created the limited account from an existing admin account and I've made a new admin account and a fake account (an account called Administrator but with no rights)
{QUOTE-> how would i check? <-QUOTE}
With Process Explorer :)
I thought that somehow you were running Explorer with admin privileges and this was the cause of being able to write "protected" folders.
{QUOTE-> i just downloaded and ran it. it has the following sections : path, read, write, deny. for example my c:\temp, has read : administrator, users. write : administrators, users.

EDIT :

ah ha! after messing around with AccessEnum and seeing just how much folders had write access : administrators, users and going into a panic :D i messed around with the "security" tab located in the folder property option. it seems there was a whole group of "users" that had "special permissions" with the following options enabled : files/folders with create folders/append enabled. and another entry for "users" that had "special permissions" with the following options enabled : subfolders with create files/append enabled. i disabled each and then tested again. lo and behold, i CANNOT create files or folders anywhere except my desktop in my limited user accounts!

now i have to do this on my desktop and my brother and sister in laws pcs. quick question : how the heck did this happen? <-QUOTE}
I don't know what to say ??? Clearly, something wasn't/isn't right. Maybe tlu has an answer :doubt:

[zopzop]

{QUOTE-> I don't know what to say ??? Clearly, something wasn't/isn't right. Maybe tlu has an answer :doubt: <-QUOTE}

all i know is thanks to you i finally figured it out :) and my LUA now acts like a LUA. i configured both my laptop and my desktop and nothing "broke" in my LUA on either machine (all the programs in my LUA run just fine. although i did have to change my downloads folders in limewire, which is to be expected).

the only thing i can think of is, i'm not using windows xp pro. i'm on windows media center. maybe MS fiddled around with the LUA in windows media center edition to make it more "user friendly" (ie save files anywhere except c:\, c:\windows, and c:\program files). also my windows media center editions aren't windows originals, they are installs from the manufacturers cds (one from HP, on my laptop, the other from gateway, on my desktop).

thanks again for your help and patience lucas :thumb:

[lucas1985]

I'm glad that I was able to help you :)
As you said, maybe Windows Media Center is somewhat different from XP Pro.

[LoneWolf]

{QUOTE-> http://www.urbandictionary.com/define.php?term=FUD <-QUOTE}

I had my answer already, but thanks for the link. :thumb:
I'm sure it will come in handy. ;D

[wat0114]

{QUOTE-> Facts and evidence, please, instead of vague FUD.
<-QUOTE}

You need to read my statements thoroughly, instead of choosing the negative so that you can eagerly lash out, as you are apt to do. To clarify in case I didn't do so already: I also use a limited account at home, and it works great. I choose how limited I want it to be so that it does not interfere with the normal operations of my programs. I also work in a corporate environment where the IT department places monumental restrictions on the O/S environment that do interfere with the normal operation of some programs and where it causes instability issues. The restrictions are too intrusive in this environment. Truth, not FUD! If administered properly, these accounts do work great (and don't forget I'm talking about XP/W2K), but overzealous restrictions do cause problems.

[solcroft]

{QUOTE-> You need to read my statements thoroughly, instead of choosing the negative so that you can eagerly lash out, as you are apt to do. To clarify in case I didn't do so already: I also use a limited account at home, and it works great. <-QUOTE}
In which case I suggest you re-read post #9 in this thread, where contrary to your dramatic beliefs that I'm out on a personal vendetta against you, you personally claimed that a limited account is overkill and a knee-jerk approach on home PCs.

It's not polite to lie, wat.

I'll tell you what will work perfectly fine in a limited account. Internet browsers and email clients will work just fine. So will word processors. Same goes for most media players (I've tried WMP, vlc and Winamp with no problems). Some games and special gaming utilities will fail, but nothing that a right-click and choosing "Run as..." won't solve. BitComet is one download utility I know of that has minor problems with a limited account, but again, nothing that can't be solved by "Run as...", or using one of the numerous fine alternatives out there.

I think that covers the majority of what the average user does with his/her PC. Unless you do debugging work on a daily basis, or something to that effect, you won't even notice that you're using a limited account. I've installed it for every friend that bothered to ask for my help, and they certainly never noticed anything different. In fact, the chances are that the more computer-illiterate one is, the less problems they'll have with a limited account, since they won't be messing around with core OS functions as much.

[lucas1985]

{QUOTE-> In fact, the chances are that the more computer-illiterate one is, the less problems they'll have with a limited account, since they won't be messing around with core OS functions as much. <-QUOTE}
Indeed. As more "standard" is your usage pattern, the less likely is LUA to cause problems.

[wat0114]

{QUOTE-> In which case I suggest you re-read post #9 in this thread, where contrary to your dramatic beliefs that I'm out on a personal vendetta against you, you personally claimed that a limited account is overkill and a knee-jerk approach on home PCs. <-QUOTE}

There was no claim you have a vendetta against me solcroft, only that you tend to lash out against anyone who states something you don't agree with.

The same paragraph I mention partial limitations are used on my own pc, so I'm all for it! I am, however, against it being administered to the extent where the machine is virtually chocked by excessive restrictions. Kids, for the most part, need a chance to try and figure things out so they can learn something, and the parent can take an active role in this. This is impossible if the restrictions are too excessive. Then you claim I'm lying :gack:

{QUOTE-> In fact, the chances are that the more computer-illiterate one is, the less problems they'll have with a limited account, since they won't be messing around with core OS functions as much. <-QUOTE}

If they want to be/stay that way, then, sure, that is perfectly fine.

[Cerxes]

{QUOTE-> ...I also work in a corporate environment where the IT department places monumental restrictions on the O/S environment that do interfere with the normal operation of some programs and where it causes instability issues. The restrictions are too intrusive in this environment... <-QUOTE}
Then the problem isn´t with LUA in itself, but that the IT administrators at your company doesn´t know, or choose to ignore, the usage-pattern of the employees. I would suggest to let them re-analyse the patterns for each targetgroup for proper configuraton of the group restrictions.

/C.

[solcroft]

{QUOTE-> There was no claim you have a vendetta against me solcroft, only that you tend to lash out against anyone who states something you don't agree with. <-QUOTE}
Of course, I do it only when I know I'm right and they're wrong. In case this sounds arrogant to you, I'm only stating a fact.

{QUOTE-> I am, however, against it being administered to the extent where the machine is virtually chocked by excessive restrictions. <-QUOTE}
That depends on what you term as restrictive. As I've said, the usual daily activities go completely unhindered by a limited account. You seem to harp incessantly on these "excessive restrictions", so from the standpoint of an ordinary computer user who doesn't edit system files, configure group policies or perform kernel debugging tasks every day, might I know what those "excessive restrictions" are?

{QUOTE-> Kids, for the most part, need a chance to try and figure things out so they can learn something, and the parent can take an active role in this. <-QUOTE}
Unfortunately, that's not what this thread is about.

{QUOTE-> Then you claim I'm lying :gack: <-QUOTE}
That's the perfectly logical conclusion to draw, judging from your claims on the detrimental effects you heap on LUA in post #9, followed by your about face turn and attack on me when all I did was to ask for the basis behind your claims. Do you have an alternate explanation?

[BlueZannetti]

To all:

How about we all drop the rhetoric a notch or two?

My take is that everyone here has made some valid points, and probably engaged in a bit of hyperbole as well.

LUA/SuRun/etc. are extremely straightforward and easily implemented solutions that are robust and have wide applicability for anyone. Occasionally, one needs to exercise a bit of finesse in using this approach, but that's it.

Although a comment regarding SRP/LUA/limited policy was made to the effect that "On a home pc, however, it is overkill", one can easily make the case that the opposite is true. What is likely overkill is a nuanced, elaborate, and customized SRP. Approaches like LUA or (my own preference) SuRun are a dozen keystrokes anyway for anyone and involve very little after that. At least in my own case, I've never experienced any of the issues (programs don't function properly, freeze, error messages abound, reboots are needed frequently) mentioned aside from single case instances which indicated a need to run at the Admin level, which immediately resolved the problem.

I do recognize that, implemented without planning or forthought, any scheme can create problems.

Blue

[EASTER]

{QUOTE-> At least in my own case, I've never experienced any of the issues (programs don't function properly, freeze, error messages abound, reboots are needed frequently) mentioned aside from single case instances which indicated a need to run at the Admin level, which immediately resolved the problem.

I do recognize that, implemented without planning or forthought, any scheme can create problems.

Blue <-QUOTE}

That's been my experience with SuRun also, in fact i only experienced one small difficulty and it was quickly resolved on it's own where i had elevated a main system file to complete a program and it appeared my account was left ADMIN instead of user. It very well could been that PrivBar add-on wasn't refreshed, at any rate there was no need to even uninstall/reinstall it again to return the permissions back as intended.

Other then that slight detour of my own doing, SuRun is been flawless and i thank everyone who is contributed to this thread with their comparisons, suggestions, and concerns as well as solutions because with the flood of security protection apps we now have readily available & effective, i wouldn't even have bothered with a LUA if not for SuRun.

[zopzop]

now that i've correctly set up a LUA (with SRP), i have a question that really does relate to the topic of this thread :D

what type of virus/trojan/malware can wreck havoc on a LUA+SRP (with autorun disabled on all removable drives)?

i mean you can't write to anywhere but your user folder and you can only run executables from your programs and windows folders. this seems foolproof no?

[Cerxes]

{QUOTE-> ...what type of virus/trojan/malware can wreck havoc on a LUA+SRP (with autorun disabled on all removable drives)?... <-QUOTE}
Malware types that:

1. Doesn´t need write/change permission for doing its evil thing.

2. Whose file extensions isn´t designated.

3. Are using known application exploits for acquiring elevated rights.

/C.

[wat0114]

{QUOTE-> Then the problem isn´t with LUA in itself, but that the IT administrators at your company doesn´t know, or choose to ignore, the usage-pattern of the employees. <-QUOTE}

You got it :thumb:

As for hyperbole, please be assured there was none intended. The kids reference was ot; sorry about that. Absolutely there is a place for lua/srp as long as it is administered correctly. There is also, in many cases, more to an office computer environment than browsers, word processors and spreadsheet programs. Some specialized programs like protocol analyzers (software based with RS232 hardware interface) and eprom burners do not work well if restrictions are overbearing or implemented incorrectly, especially when the registry and custom-built scripts are involved.

[solcroft]

{QUOTE-> Malware types that:

1. Doesn´t need write/change permission for doing its evil thing.

2. Whose file extensions isn´t designated.

3. Are using known application exploits for acquiring elevated rights.

/C. <-QUOTE}
You forgot #4: that don't need to be executed to cause damage.

[lucas1985]

Is there any example of malware (excepting macro/script viruses and network worms exploiting vulnerable services) that infects/installs under LUA + SRP?

[zopzop]

@cerxes and solcroft

good grief! i thought LUA+SRP was more secure than that :-\

i basically wanted to cut back on the number of security apps on my brother and his wife's machines (as to not confuse them) and just go with LUA+SRP+real time antivirus. hmm i guess i'll keep geswall on their PCs too.

real quick question, i added a a few extensions to the SRP block list (that were not in the default list created by the SRP and handled by script defender) found here :
http://www.wilderssecurity.com/showpost.php?p=1089855&postcount=4

will this help stop script viruses?

[Cerxes]

{QUOTE-> You forgot #4: that don't need to be executed to cause damage. <-QUOTE}
No I didn´t forget about that ;), but malware, either it´s binary code or scripts, have to execute in its initial stage so it´s part of no.2 in SRP's file extension list.

How can any code be malicious and cause damage if it can´t execute, will not execute because some part of the code is crippled or the target for the codeinstruction is missing?

{QUOTE-> ...good grief! i thought LUA+SRP was more secure than that... <-QUOTE}
Using Windows own policy restrictions is a very powerful and straightforward way of achieving a high degree of security. However, nothing is 100 percent for certain, but you can at least minimize the damage using this type of damagecontrol since it doesn´t alter the vital areas of your system.

{QUOTE-> ...will this help stop script viruses? <-QUOTE}
It stops every file extension that you designate, but I don´t know about its capacity of analysing the scripts, in case of injections etc. By the way, these are the extensions I´m currently blocking:

.ADE,.ADP,.BAS,.BAT,.CHM,.CMD,.COM,.CPL,.CRT,.EML,.EXE,.HLP,.HTA,.INF,.INS,.ISP,.JS,.JSE,.MDB,.MDE,.MSC,.MSG,.MSI,.MSP,.MST,.OCX,.PCD,.PIF,
.REG,.SCR,.SCT,.SHB,.SHS,.URL,.VB,.VBE,.VBS,.WSC,.WSF,.WSH,.XLM,.XLS

/C.

[solcroft]

{QUOTE-> @cerxes and solcroft

good grief! i thought LUA+SRP was more secure than that :-\ <-QUOTE}
zopzop,

Obviously you missed my intended point. Malware that falls under category #4 does not exist and never will.

The one loophole I can think of is a DLL trojan that drops itself to your user folders and uses a script to invoke rundll32 to load it, AND then exploits a privilege escalation vulnerability. But in all honesty, if you ever chance upon such a trojan, I highly recommend you start buying the lottery.

[SystemJunkie]

{QUOTE->
Quote:
Originally Posted by zopzop
...what type of virus/trojan/malware can wreck havoc on a LUA+SRP (with autorun disabled on all removable drives)?...
Malware types that:

1. Doesn´t need write/change permission for doing its evil thing.

2. Whose file extensions isn´t designated.

3. Are using known application exploits for acquiring elevated rights.
<-QUOTE}Very good info.

{QUOTE-> .ADE,.ADP,.BAS,.BAT,.CHM,.CMD,.COM,.CPL,.CRT,.EML,.EXE,.HLP,.HTA,.INF,.INS,.ISP,.JS,.JSE,.MDB,.MDE,.MSC,.MSG,.MSI,.MSP,.MST,.OCX,.PCD,.PIF,
.REG,.SCR,.SCT,.SHB,.SHS,.URL,.VB,.VBE,.VBS,.WSC,.WSF,.WSH,.XLM,.XLS <-QUOTE}
Good idea, how do you block?

[Rasheed187]

What most people seem to forget (or don´t mention that often) is the fact that as soon as you need to install some app, you have no choice but to give it admin rights. Meaning that HIPS (+brain.exe) will be the only thing that might save your ass.

I think LUA is mostly focused on protecting you against drive by attacks and against malicious apps that don´t need to be installed. But some of this can also be achieved on an admin account with DMR/SRP. Of course LUA is the better approach.

But because I´m mostly worried about malware who tries to integrate deeply into the system (via manual launch), I would like my LUA to work in a way that it would have write access only to the needed registry keys and to the "program files" folder (not to the subfolders!). This way most apps would be able to install correctly, and if they tried to act funny and are even able to bypass HIPS, they can´t do any serious damage. Is this possible, or am I missing something? ::)

[solcroft]

{QUOTE-> But because I´m mostly worried about malware who tries integrate/do damage deeply into the system, I would like my LUA to work in a way that I would have write access to the needed registry keys and to the "program files" folder. This way most apps will be able to install correctly, and if they try to act funny and are even able to bypass HIPS, they can´t do any serious damage. Or am I missing something? ::) <-QUOTE}
How will LUA be able to stop them from doing "any serious damage" when you've effectively given the app access to the "needed registry keys" and Program Files folder?

[Rasheed187]

{QUOTE-> How will LUA be able to stop them from doing "any serious damage" when you've effectively given the app access to the "needed registry keys" and Program Files folder? <-QUOTE}

Solcroft, you might want to fix that qoute, I have edited my post. But to answer your question, if I´m correct, LUA won´t allow any modifications to kernel right? So with my approach, even if you allow apps to be installed, they can´t do any serious damage. Of course, HIPS still comes in handy, because it´s most likely that blocking executables from running will immediately stop a drive by attack. But the question is if it is possible to give write access to only certain regkeys (which are needed by most apps) and to deny access to all other sensitive keys? Probably not, and that´s the problem, which of course can be solved by HIPS, if it monitors the right keys, and if it isn´t bypassed.

[solcroft]

{QUOTE-> But to answer your question, if I´m correct, LUA won´t allow any modifications to kernel right? So even if you allow apps to be executed they can´t do any seriou s damage. <-QUOTE}
It depends on your definition of "serious" damage. Not all malware needs kernel access to deliver their payload. I mean, for instance, if you don't consider as "serious" all your executables in %ProgramFiles% being infected, or a keylogger being installed...

It's all in the definition.

{QUOTE-> But the question is if it is possible to give write access to only certain regkeys (which are needed by most apps) and to deny access to all other sensitive keys? <-QUOTE}
Yes you can.

[Rasheed187]

{QUOTE-> I mean, for instance, if you don't consider as "serious" all your executables in %ProgramFiles% being infected, or a keylogger being installed... <-QUOTE}

And this can´t happen if you install some app yourself? At least a HIPS will be able to notify you if some app has been modified. As a matter of fact, M$ could have implemented a security policy, that wouldn´t allow subfolders in program files to be modified. Something that HIPS can also do.

{QUOTE-> Yes you can. <-QUOTE}

Perhaps an idea to start a thread about it. To clarify, if you install apps, they will (almost?) always need to modify regkeys in HKLM, but that´s exactly where sensitive keys, who may be abused, are stored, correct?

{QUOTE->
Of course, HIPS still comes in handy, because it´s most likely that blocking executables from running will immediately stop a drive by attack. <-QUOTE}

I forgot to mention that HIPS might also give you valuable clues, even if it´s bypassed. For example, I did get an alert about Rootkit Agent EZ trying to directly access memory (high risk), but the damage should have been stopped by LUA anyway. Still, without HIPS I wouldn´t even have known that I was under attack. So, LUA + HIPS/security tools is the way to go. :thumb:

[solcroft]

{QUOTE-> And this can´t happen if you install some app yourself? At least a HIPS will be able to notify you if some app has changed. <-QUOTE}
Not sure what your point is. You asked, and I quote, "even if you allow apps to be executed they can´t do any seriou s damage." I was merely providing an explanation.

{QUOTE-> As a matter of fact, M$ could have implemented a security policy, that wouldn´t allow subfolders in program files to be modified. <-QUOTE}
Er, they did, actually.

{QUOTE-> I forgot to mention that HIPS might also give you valuable clues, even when bypassed. For example, I did get an alert about Rootkit Agent EZ trying to directly acess memory (high risk), <-QUOTE}
Erm, yes... I suppose that's very helpful...

{QUOTE-> but the damage should have been stopped by LUA anyway. Still, without HIPS I wouldn´t even have known that I was under attack. So, LUA + HIPS/security tools is the way to go. :thumb: <-QUOTE}
Well, not for me, sorry. I don't need to be bothered by useless alerts that might possibly mean that I'm "under attack" when that "attack" has been completely defanged and castrated by LUA.

[Rasheed187]

{QUOTE-> Not sure what your point is. You asked, and I quote, "even if you allow apps to be executed they can´t do any serious damage." I was merely providing an explanation <-QUOTE}

I think I´ve started to confuse you. My point is: Where the heck is your defense (in LUA) when you install some app yourself? This app will have admin rights, and will be able to do just about anything. So, it seems like LUA is mainly meant to protect against drive by/remote code execution attacks. And it´s my impression that HIPS will stop most of these attacks anyway, even when running as admin.

{QUOTE-> Er, they did, actually. <-QUOTE}

Yes, but only in LUA. As admin you can still infect/replace files, no? My point: even as admin there should have been certain restrictions. Of course if needed, you could then give trusted apps "full admin" rights.

{QUOTE->
Well, not for me, sorry. I don't need to be bothered by useless alerts that might possibly mean that I'm "under attack" when that "attack" has been completely defanged and castrated by LUA. <-QUOTE}

This sounds strange to me, then why are you running tools like TF? Oh wait, I forgot, TF isn´t that noisy, I suppose you meant something like that.

[lucas1985]

{QUOTE-> The one loophole I can think of is a DLL trojan that drops itself to your user folders and uses a script to invoke rundll32 to load it, AND then exploits a privilege escalation vulnerability. But in all honesty, if you ever chance upon such a trojan, I highly recommend you start buying the lottery. <-QUOTE}
Scripts are always the loophole in our search for the "bullet-proof" security setup.
{QUOTE-> I would like my LUA to work in a way that it would have write access to the needed registry keys and to the "program files" folder. This way most apps will be able to install correctly, and if they try to act funny and are even able to bypass HIPS, they can´t do any serious damage. Is this possible, or am I missing something? ::) <-QUOTE}
Create an account with custom permissions. So, you'll have the admin account, the limited account and the custom account for installing apps which you don't trust completely.
You can fine-tune read/write/execution permissions to your heart's content in XP Pro.

[Rasheed187]

{QUOTE-> Create an account with custom permissions. So, you'll have the admin account, the limited account and the custom account for installing apps which you don't trust completely. <-QUOTE}

Yeah, I guess I should try to do this, but how is the question. I´m not exactly an expert when it comes to permissions and stuff, it all seems so complicated to me. Besides, M$ should have figured this out for me, and they should have build the OS in a smarter way! :dry:

[lucas1985]

{QUOTE-> how is the question. <-QUOTE}
You can start here (http://www.pcguide.com/ref/hdd/file/ntfs/sec.htm) :)
{QUOTE-> I´m not exactly an expert when it comes to permissions ans stuff, it all seems so complicated to me. <-QUOTE}
Security in-depth isn't easy.

[wat0114]

You should probably not need to allow more than what is shown in the screenshot for key directories, such as Windows & its sub-folders. I can tell you that the "Delete Mount" exploit talked about in another thread was unsuccessful with these and similar restrictions on the Program files directory. Others will probably have different opinions, so go with whom you have more faith in :) Lucas, Cerxes, solcroft and Mrkvonic clearly have an excellent understanding on this subject matter, to name the ones I can think of. Whatever you do, take your time, read up all you can on this and be careful. Don't just impose these restrictions willy-nilly without understanding what you are doing, otherwise you could lock yourself out of your account.

Maybe Surun is your best bet? Others have positive things to say about it.

[solcroft]

{QUOTE-> I think I´ve started to confuse you. My point is: Where the heck is your defense (in LUA) when you install some app yourself? This app will have admin rights, and will be able to do just about anything. So, it seems like LUA is mainly meant to protect against drive by/remote code execution attacks. And it´s my impression that HIPS will stop most of these attacks anyway, even when running as admin. <-QUOTE}
How does HIPS protect you either when you install a new program? How do you know whether it's needed for that new program to install a driver, or register a 32-bit DLL, or installs a program-specific/global hook when you've never seen it before? Either you trust the program and allow, or you don't and you deny. That's not really much different from what a limited account does for you. You elevate privileges if you trust, you don't if otherwise.

{QUOTE-> Yes, but only in LUA. As admin you can still infect/replace files, no? My point: even as admin there should have been certain restrictions. Of course if needed, you could then give trusted apps "full admin" rights. <-QUOTE}
But you wouldn't be protected in "full admin"! Omigosh. Shouldn't there still be restrictions in "full admin", and if you really really trust the program you can give it "full full admin" rights? But of course you still wouldn't be protected in "full full admin". Maybe there should be "full full full admin" rights too.

{QUOTE-> Yeah, I guess I should try to do this, but how is the question. I´m not exactly an expert when it comes to permissions and stuff, it all seems so complicated to me. Besides, M$ should have figured this out for me, and they should have build the OS in a smarter way! :dry: <-QUOTE}
Would you like it to make coffee and fetch slippers for you too?

[AndrewL]

LUA+SRP may not be a perfect solution but it is a fairly good start.


If software is buggy, unstable or limited in functions because of LUA, that is a problem caused entirely by the software developer who does not work (or properly test) from a limited account. Considering that a large chunk of a developers income is likely to come from the corporate sector (which usually uses LUA) this is inexcusable. MS guidelines are clear enough.

If the user is smart enough to avoid trouble then an administrator account then by all means, go for it. However, for most users there is no good reason for it.
Too many times I have heard the line "I own the computer so I am the administrator" from people who do not have the smarts to fix their own broken computer. That's fine, I'll take your money...

Cheers

[Mrkvonic]

Hello,
Actually, in the corporate sector, I have never ever seen a single computer running LUA - and very few policies...
Mrk

[aigle]

Why so?

[solcroft]

Incompetent network admins, probably.

[Mrkvonic]

Hello,

aigle, why? Because most users will cut their veins if their precious Outlook / Office does not open their precious emails / ppts - typical corporate worker usage.

We have an IT team answering 100 calls every day along the line - where has my cursor gone, I deleted my icons etc... landing them with a LUA / SRP would obliterate them.

And think of the comptence of IT personnel you need. Not everyone is capable of properly using policies. If you have smart people, you can save millions, but otherwise, it's a nightmare. You might as well land Linux into the desktops.

Mrk

[sukarof]

{QUOTE-> Hello,
Actually, in the corporate sector, I have never ever seen a single computer running LUA - and very few policies...
Mrk <-QUOTE}

Really?! Wow. In all the companies I have worked in LUA is always standard and no one has problems running the software they need for work. The software is thorougly tested to work with restricted accounts.
Ok, I havent worked in that many companies but I find it very scary if a company has a IT department and they allow admin on clients especially if they are connected to internet (and which companies are not connected today?)

[Mrkvonic]

Hello,

Combine incompetence with rudeness and lack of patience and you get admin accounts or the IT manager gets crucified within a week. But seriously, from what I've seen, it seems the only way that works with masses of computer-uninterested users.

Most people also install crap they are not supposed to - even at work place. And then they wonder why things don't work - and pester the IT to solve their problems.

I'm not in IT, but if I took a dollar for every case of help I provided to my co-workers, just because I know a little more than they, I think I could have earned 675 dollars so far. And imagine that for every one I helped, another 4 phone the IT instantly and whine:

- I erased my desktop shortcut icon (even better, it vanished - like a sentient thing).
- My mails are gone.
- My computer is slow (no shit, the company image on laptops runs 80+ processes).
- I get errors trying to open this webpage.
- Why does WU always trying to restart the computer?

That's my experience in companies.

Mrk

[Rmus]

{QUOTE-> Most people also install crap they are not supposed to - even at work place. <-QUOTE}The only one to blame is the person who sets policy for the company. The company computer is not an employee's personal computer.

It can be done:

http://www.faronics.com/whitepapers/CaseStudy_LAPD.pdf

“We currently have a policy that prohibits unauthorized installation of non-Department sanctioned/
owned software on any Department computer,” said Mr. Riley. “


----
rich

[solcroft]

{QUOTE-> It can be done: <-QUOTE}
It not only can be done, it should be done. I don't know what corporations Mrkvonic has seen, or whatever their minimum criteria are for hiring network admins, but the problems he describes can be prevented by properly-implemented policies. The issues his IT department faces aren't caused by limited accounts and policies, it's caused by the LACK of them.

[Rmus]

{QUOTE-> It not only can be done, it should be done. <-QUOTE}It's also being done in more educational institutions.

Where I taught, all workstations had Deep Freeze so that no students could make any permanent changes.

This has an interesting added bonus: workstations in computer science classrooms run in Administrative mode so that students can do exercises to configure Networking and make Registry changes.

Upon reboot, the machines revert to previous good state.


----
rich

[solcroft]

{QUOTE-> It's also being done in more educational institutions. <-QUOTE}
As is done here. It makes for a pretty restrictive network, but I wouldn't dare to imagine it any other way, if only for the havoc I know other people can wreak if they were allowed to. Normal engineering and CAD/CAM applications run fine, you can browse the web, listen to music, use some portable apps that don't require admin rights etc, and everyone gets a stable, secure network.

Now imagine if teenage students came and installed whatever they pleased on the shared network PCs. I can't imagine why any competent network admin WOULDN'T want to implement policies and/or LUA.

[Rmus]

{QUOTE-> It makes for a pretty restrictive network, but I wouldn't dare to imagine it any other way, if only for the havoc I know other people can wreak if they were allowed to. <-QUOTE}8 or 9 years ago when these policies were implemented, many people griped. But the gripes diminished over time, and everyone began to appreciate the change from 150+ service calls/month on three campuses for mishaps and messed up computers , to 0 (that's Zero) calls for such problems.


----
rich

[Rasheed187]

{QUOTE-> How does HIPS protect you either when you install a new program? How do you know whether it's needed for that new program to install a driver, or register a 32-bit DLL, or installs a program-specific/global hook when you've never seen it before? Either you trust the program and allow, or you don't and you deny <-QUOTE}

Now you´re starting to sound like a certain someone who tried to convince people that they don´t know how to use HIPS. I think I already explained my approach to all of this, but if you insist, I will do it again. Let me ask you one question: what if some app tries to modify your apps in "program files", you wouldn´t find this strange? I mean you came up with this example yourself. Also, just because I install some app doesn´t mean I (have to) trust it 100%! What if you upgraded your browser, and all of a sudden it starts to do (high risk) stuff that it never wanted to do before?

{QUOTE-> But you wouldn't be protected in "full admin"! Omigosh. Shouldn't there still be restrictions in "full admin"... <-QUOTE}

Funny and you do got a point, but I will try to explain it better: I´m saying that it would be cool if you could install apps inside LUA without the need to give them "full admin" rights. Because right now there is in fact no difference between installing apps in LUA or admin mode, the risk stays the same. So in order to make this plan work, LUA should be modified in a way that apps should have just enough rights to be able to modify only certain parts of the file system and registry.

And I don´t know if it´s possible (with current NTFS system) to deny apps from modifying only subfolders inside program files (because they all should get write permission), so why not virtualize file and registry modifications, like in Vista? Of course these are all ideas, and I´m just an amateur, but I´m sure that the bright folks at M$ who spend millions of dollars on R&D could come up with something. ::)

[Rasheed187]

I also need to clarify that this "tweaked LUA" thing is only for geeks/paranoid folks like me, because noobs would probably give "full admin rights" right away if they see that certain apps can not be installed correctly.

But for me LUA would become a nice extra layer (which it already is, but only better) and would give me a way to analyze apps without even having to worry about my HIPS being bypassed, for the most part. I say "for the most part", because you still need to rely on HIPS when it comes to certain stuff, unless you would make this "Safer LUA" thing even more restrictive. And then we are indeed starting to talk about stuff like "full-full admin rights". :D

[MrBrian]

Some things that software running under LUA can do, at least under XP:
a) modify your data files
b) steal your data files
c) log your keystrokes/screenshots and send them to a remote computer
d) obtain autostart capability in the several autostart locations allowed to change under LUA by default
e) since programs running under LUA can modify other processes owned by the same user, including Windows Explorer and Task Manager, it is possible for malware to hide its presence from these Windows programs
f) buffer overflow exploits can run and do the above actions, although constrained by LUA, unless you are using Software Restriction Policies, HIPS with execution control, etc., to prevent execution

Can anybody confirm or refute the above statements?

[Dogbiscuit]

Malware that can run with the privileges of the current user should work AFAIK.

[tlu]

{QUOTE-> Some things that software running under LUA can do, at least under XP:
a) modify your data files
b) steal your data files
c) log your keystrokes/screenshots and send them to a remote computer
d) obtain autostart capability in the several autostart locations allowed to change under LUA by default
e) since programs running under LUA can modify other processes owned by the same user, including Windows Explorer and Task Manager, it is possible for malware to hide its presence from these Windows programs
f) buffer overflow exploits can run and do the above actions, although constrained by LUA, unless you are using Software Restriction Policies, HIPS with execution control, etc., to prevent execution

Can anybody confirm or refute the above statements? <-QUOTE}
MrBrian, that's why I always recommend to
combine LUA with SRP. Remember: Malware has to be executed in order to do anything harmful. SRP prevents that.
protect the autostarts of your limited account by applying kafu.exe (http://www.wilderssecurity.com/showpost.php?p=1190510&postcount=93) as an additional measure (why? (http://www.wilderssecurity.com/showpost.php?p=1192607&postcount=123))
keep not only Windows but also your applications updated by using such tools like Sumo, Updatestar or Secunia Personal Software Inspector.

BTW: A very good post worth being read is this (http://www.wilderssecurity.com/showpost.php?p=1192141&postcount=115) one by lucas1985.

[Cosmo 203]

{QUOTE-> Some things that software running under LUA can do, at least under XP:
a) modify your data files
b) steal your data files
c) log your keystrokes/screenshots and send them to a remote computer
d) obtain autostart capability in the several autostart locations allowed to change under LUA by default
e) since programs running under LUA can modify other processes owned by the same user, including Windows Explorer and Task Manager, it is possible for malware to hide its presence from these Windows programs
f) buffer overflow exploits can run and do the above actions, although constrained by LUA, unless you are using Software Restriction Policies, HIPS with execution control, etc., to prevent execution <-QUOTE}

What does this mean?
Regarding a): This is what a computer is made for. If you stop the computer from this possibility you can watch TV (also without being able to modify anything).
b) ... First question: Which software? If the owner of a pc installs software, which does this, LUA is not even expected to prevent the result of such a stupidity. As I said already several times: Without switching on the brain you can forget about LUA, HIPS or what people like. Until today there is no computer software which rules on a higher level than a human brain (and I hope, that we do not find one day, that computer rule the world).

[MrBrian]

{QUOTE-> MrBrian, that's why I always recommend to
<-QUOTE}

Thanks tlu :). I haven't read the main relevant threads thoroughly yet, but I will before I try LUA.

[MrBrian]

{QUOTE-> What does this mean?
<-QUOTE}

Since I haven't used LUA in years, I just wanted to make 100% sure of the statements I made, although I already was pretty sure of all of them anyway except for maybe statement e). I made the list so that others (and also I) can see what other security measures they might wish to use in conjunction with LUA, such as anti-malware scanners, SRP, HIPS, etc. Here's an example: if you use LUA and ran kafu.exe once, but don't also use execution prevention measures and/or a firewall with outbound control, you could be affected by a buffer overflow exploit (statement f) that transmits your personal documents to bad guys (statement b).

[Rmus]

A friend is considering setting up Limited User Accounts (LUA) on his XP-Home system for others in his household,
and was hoping that it will lock down the computer so that others can not install software. He found this not to be so
in some cases -- as indicated in the description of a LUA in the account setup:

{QUOTE-> Users with limited accounts cannot always install programs. <-QUOTE} Implying that sometimes they can.

I decided to set up a LUA and see for myself, and compare with Anti-Executable (AE).

Test 1 - download/install program from the internet

In the LUA I was able to download a program's setup.exe to the desktop and install the program to C:\

200716
________________________________________________________________

With AE enabled, the download was aborted:

200711
________________________________________________________________

Test 2 -extract program from a .zip file

I copied a small self-contained program in a zip file from my USB drive to the Desktop
and was able to extract the program and run it from the desktop while in the LUA:

200712
_________________________________________________________________

With AE enabled, the extraction was blocked:

200713
__________________________________________________________________

Test 3 -install program from a CD

Here, the installation failed in a LUA because a file could not be written to the Windows Directory.
Files are left behind. With AE enabled, the installation fails to start, hence, nothing written anywhere:

200714
___________________________________________________________________

It seems that you need an additional safeguard if you want to control installation of programs
when others use your computer in a LUA.


----
rich

[MrBrian]

{QUOTE->
It seems that you need an additional safeguard if you want to control installation of programs when others use your computer in a LUA.
<-QUOTE}

That's right. That's why others suggest to also use SRP to allow execution only from \Program Files and \Windows.

[EASTER]

Nice one Rmus, but i wonder if you would get the same results with LUA if combined with a SRP?

Still, it shows a plain-jane LUA is not enough, but you gotta hand it to Faronic's for their Anti-Executable program and it's specialty measure of "code detection" that tips the balance in a users favor the majority if not all the time.

I wonder if the LUA app SuRun would be so liberal or generous in comparison though. It's these type tests and others that shed light in pictures that gets people motivated.

Thanks for the screens and tryout. LoL

[MrBrian]

From The Case of the Insecure Security Software (http://blogs.technet.com/markrussinovich/archive/2007/06/19/1256677.aspx):

{QUOTE-> To my surprise and dismay, I found security holes in several namespaces. The security settings on one application’s global synchronization and memory mapping objects, as well as on its installation directory, allow unprivileged users to effectively shut off the application, corrupt its configuration files, and replace its executables to elevate to Local System privileges. What application has such grossly insecure permissions? Ironically, that of a top-tier security vendor. <-QUOTE}

{QUOTE-> In the wake of my discovery, I analyzed the rest of my systems, as well as trial versions of other popular security, game, ISP and consumer applications. A number of the most popular in each category had problems similar to those of the security software installed on my development system. I felt like I was shining a flashlight under a house and finding rotten beams where I had assumed there was a sturdy foundation. The security research community has focused its efforts uncovering local elevations via buffer overflows and unverified parameters, but has completely overlooked these obvious problems – problems often caused by the software of security ISVs, or in some cases, their own.

Why are these holes created? I can only speculate, but because allowing unprivileged groups write-access to global objects requires explicit override of secure defaults, my guess is that they are common in software that was originally written for Windows 9x or assumed a single administrative user. When faced with permissions issues that crop up when migrating to a version of Windows with security, or that occur when their software is run by standard user accounts, the software developers have taken the easy way out and essentially turned off security. <-QUOTE}

[Rmus]

{QUOTE-> That's right. That's why others suggest to also use SRP to allow execution only from \Program Files and \Windows. <-QUOTE}Good suggestion! But in this case,

1) he has XP-Home

2) he is not the type to want to configure policies.

{QUOTE-> i wonder if you would get the same results with LUA if combined with a SRP? <-QUOTE}My understanding from SpikeyB whom I've sent many links to drive-by downloads, is that using SRP, the executable can download (copy) to disk but cannot execute.


----
rich

[EASTER]

{QUOTE->

My understanding from SpikeyB whom I've sent many links to drive-by downloads, is that using SRP, the executable can download (copy) to disk but cannot execute.


----
rich <-QUOTE}

So there is (tongue-in-cheek) some added value to LUA so long as in tandem with an SRP, but wonder if that's even enough. Most say yes and i'm inclined to agree, but as one who is relied heavily on running ADMIN for so long, and hitting the meanest sites in researching tit for tat against various security programs to see how they fair, i run into a dilema.

It's IMO to a users advantage to gain an understanding and measure at the same time the levels of forced intrusion attempts versus their selection of the security combos of choices, and falls to which one they have experienced positive results with when engaged in this sort of on-air combat.

I think XP Systems have been taken to task, and may go down in history as the most challenged O/S that Microsoft will have ever developed, and a lot of that credit MUST go to the efforts of the security vendors who have come out with a vengeance to battle heads up with whatever is been devised to compromise these NT Systems.

On a side note, do you have an opinion on the LUA app SuRun and would you put more stock/confidence in it then simply the plain LUA when compared together?

[Rmus]

{QUOTE-> So there is (tongue-in-cheek) some added value to LUA so long as in tandem with an SRP, <-QUOTE}I believe he does not run in a LUA - just uses SRP.

{QUOTE-> On a side note, do you have an opinion on the LUA app SuRun and would you put more stock/confidence in it then simply the plain LUA when compared together? <-QUOTE}I haven't tried it. I have always run as Administrator on my Win2k system, and I set up a LUA today on my laptop XP-Home only to run tests to see about preventing unauthorized downloading of software.

A couple of quirky things I noticed: In my screenshot showing WinZip, it indicates "Unregistered." However, I've been a licensed user of WinZip for 15 years. For some reason, switching to LUA changes something.

Also, one of my most-used utilities, the MS PowerToy "Send-To" which appears on the r-click context menu, does not show up when in LUA. So, I'm suspicious that there may be problems with other applications.

On a Plus-note: When using TweakUI, a number of the items do not show up when in LUA. AutoPlay for drives, as an example. As you know, TweakUI is a GUI for editing the Registry, so it is natural that certain functions will be restricted when using a LUA account.

However: OK to restrict other users of your computer. But as the sole user here, I would find it cumbersome to have to do some type of switching when necessary to gain Administrator rights. That's not to say it wouldn't be ideal for others. But I've never had any fear about running as Administrator.

{QUOTE-> It's IMO to a users advantage to gain an understanding and measure at the same time the levels of forced intrusion attempts versus their selection of the security combos of choices, and falls to which one they have experienced positive results with when engaged in this sort of on-air combat. <-QUOTE}I've always maintained that if a user has this understanding of how malware gets onto the computer, not much security software is needed from the prevention standpoint.


----
rich

[tlu]

@Rmus: I think you misunderstood LUA. Its purpose is that you don't have write permission for the biggest part of the registry, for c:\Windows and c:\Program Files. That means that all critical parts of your system and your applications are protected against deletion/modification/manipulation without the need of a HIPS, and the unwanted installation of a driver or rootkit etc. is impossible. Nobody ever said that it isn't possible to install applications to other folders than the default c:\Program Files (since a limited user can create folders beneath, e.g., c:\ ) as long as they don't want to create/modify files somewhere in c:\windows or create/modify keys in, e.g., HKLM. It only means that these applications aren't protected against modification since the user has write permission to that folders.

Again, LUA alone doesn't imply an execution control. You can execute any application with limited rights but it isn't able to seriously harm your system. If you want execution control you have to combine it with SRP or an AE.

[tlu]

{QUOTE-> I believe he does not run in a LUA - just uses SRP. <-QUOTE}
This wouldn't make any sense if he configured SRP as recommended in this thread as only limited users are affected. An admin can execute any application anywhere.

{QUOTE-> I haven't tried it. I have always run as Administrator on my Win2k system, and I set up a LUA today on my laptop XP-Home only to run tests to see about preventing unauthorized downloading of software. <-QUOTE}
See my previous post.

{QUOTE-> A couple of quirky things I noticed: In my screenshot showing WinZip, it indicates "Unregistered." However, I've been a licensed user of WinZip for 15 years. For some reason, switching to LUA changes something. <-QUOTE}
I haven't used Winzip for many years (I'm using the excellent and free 7zip instead) and I don't know how you implemented LUA. But if you registered it in your admin account and it says "unregistered" in your limited account that means that the registration info is written to HKCU or the "Documents and Settings" folder of the admin account which are not accessible from your limited account. This seems to be a badly written application. An application that is not aware of multiple user accounts (that were introduced with Windows NT in the '90s!) is obviously designed for Win 9x. Its programmers still live in the past.

{QUOTE-> Also, one of my most-used utilities, the MS PowerToy "Send-To" which appears on the r-click context menu, does not show up when in LUA. So, I'm suspicious that there may be problems with other applications. <-QUOTE}
Can't comment that since I don't use it. Anybody else?

{QUOTE-> However: OK to restrict other users of your computer. But as the sole user here, I would find it cumbersome to have to do some type of switching when necessary to gain Administrator rights. That's not to say it wouldn't be ideal for others. But I've never had any fear about running as Administrator. <-QUOTE}
But that "switching" is a comfortable 2-mouseclicks-task with SuRun. It really makes life considerably easier - you should try it. Besides, I don't need admin rights for my normal daily activities - why do you?

{QUOTE-> I've always maintained that if a user has this understanding of how malware gets onto the computer, not much security software is needed from the prevention standpoint. <-QUOTE}
Exactly. That's why LUA + SRP is a much easier and built-in solution compared to any HIPS. You set it up once and that's it. No need to cumbersome configuration and finetuning.

[MrBrian]

From Windows Access Control Demystified (www.cs.princeton.edu/~sudhakar/papers/winval.pdf):

{QUOTE-> We used our tool to see how software is configured by vendors in the default installation, on a professionally managed network of Windows XP client machines with AOL, Adobe and Macromedia software in standard configurations. The results, as shown in figure 1, indicate that unprivileged users can gain administrator privileges through several paths... <-QUOTE}

{QUOTE-> We also believe that buggy access-control configuration is a problem that could affect vendors and operating system versions not discussed in this paper. There is no reason to believe that only developers at Adobe, AOL, Macromedia and Microsoft made mistakes in access-control configuration. Our views are vindicated when we found similar bugs in a commonly used product from a different vendor very close to preparing the final version of this document. Even if the operating system is secure at installation time, it is worrisome that it could become insecure upon installing commonly used (required) software. <-QUOTE}

[MrBrian]

Limited users - myth or reality (http://hype-free.blogspot.com/2007/02/limited-users-myth-or-reality.html)

[Rmus]

{QUOTE-> @Rmus: I think you misunderstood LUA. <-QUOTE}Yes, and a few other people, as I've discovered recently. I had been led to believe from comments by others that only the Adminstrator can install programs. That's why I tested, to find out for sure.


----
rich

[tlu]

{QUOTE-> Yes, and a few other people, as I've discovered recently. I had been led to believe from comments by others that only the Adminstrator can install programs. That's why I tested, to find out for sure.
<-QUOTE}

I understand. But that's only the case if write access to the above mentioned protected areas is required during the installation process which most apps request in some way or another. With SRP you wouldn't even be able to install these apps with limited rights unless you specified a New Path Rule in SRP for the folder where the installation/setup files are stored. And if you installed them to a folder other than c:\Program Files you wouldn't be able to execute them with limited rights unless you specified a New Path Rule for that folder. ;) I guess you realize that the combination of LUA and SRP provides pretty tight control while its application is very easy once you've understood the logic which is actually rather simple.

[Rmus]

Yes - you explain it very well. Thanks.


----
rich

[MrBrian]

Symantec released a paper called 'The Impact of Malicious Code on Windows Vista' (www.symantec.com/avcenter/reference/Impact_of_Malicious_Code_on_Vista.pdf) shortly after the launch of Vista.

{QUOTE->
To measure the impact of malicious code on Windows Vista, Symantec developed a framework to execute and track the behavior of a large number of malicious code samples. The majority of this malicious code targets Windows XP and previous versions of Microsoft Windows. As a result it was found to be much less effective when executed on Windows Vista. As Windows Vista becomes widely deployed, we expect that attackers will adapt to its new environment. As we have shown, threats can already execute within the confines of Vista’s more restricted environment. In addition, research conducted outside the scope of this paper has shown that threats may leverage techniques to elevate their privilege to that of a full Administrator. Although Microsoft recently deferred from calling it a security boundary, UAC is designed to provide another layer of protection. With access to sensitive information, networking capabilities, and the ability to survive system reboots, we expect that threats already have the required functionality in order to propagate in the Windows Vista environment today. <-QUOTE}

[MrBrian]

{QUOTE->
1) he has XP-Home
<-QUOTE}

There is a program called SetSAFER that lets you use SRP in XP Home.

[Dogbiscuit]

{QUOTE-> That means that all critical parts of your system and your applications are protected against deletion/modification/manipulation without the need of a HIPS, and the unwanted installation of a driver or rootkit etc. is impossible.

You can execute any application with limited rights but it isn't able to seriously harm your system. <-QUOTE}
@tlu: When implementing LUA alone, privilege escalation exploits (especially the more common local type) are capable of breaking out of the limited account and compromising the OS, right?

[MrBrian]

{QUOTE-> When implementing LUA alone, privilege escalation exploits (especially the more common local type) are capable of breaking out of the limited account and compromising the OS, right? <-QUOTE}

I'm not tlu, but I'll give my answer. The answer is yes. However, malware cannot do privilege escalation if it cannot run in the first place due to SRP, HIPS, etc. Posts #89 and 95 address privilege escalation.

[MrBrian]

I believe that LUA and SRP properly configured might still be vulnerable to malware execution. Here is how:
a) Assume that a buffer overflow exploit occurs and is not caught by DEP, etc.
b) The buffer overflow shellcode downloads an executable file with a nonstandard extension such as .tmp in a nonstandard location. C:\index.tmp would be an example.
c) The buffer overflow shellcode executes C:\index.tmp, and thus you have malware running, even with LUA and SRP, provided that SRP does not stop the execution of c:\index.tmp. I am not sure if SRP would block this or not. If SRP looks merely at extensions and not content, then I would guess SRP would not block this. (Technically, you already had malware running when the buffer overflow shellcode was running, but the shellcode usually just downloads executable code and runs it.)

This is illustrated here (http://blog.threatfire.com/2008/06/tracking-coreflood-from-shellcode.html).

[Dogbiscuit]

{QUOTE-> I'm not tlu, but I'll give my answer. The answer is yes. However, malware cannot do privilege escalation if it cannot run in the first place due to SRP, HIPS, etc. Posts #89 and 95 address privilege escalation. <-QUOTE}
Thanks for pointing out those posts as this has become a long thread.

The point I was trying to bring up was that LUA alone can protect the OS (but not the limited account) if the user is generally careful. But not necessarily if the limited user is careless (or malicious).

[soldataq]

actually me thinks limited user can get you infected for limited user files only but i may be wrong.



soldataq

[Cosmo 203]

Small, but important correction (I set it bold here:)

{QUOTE-> I believe that LUA and SRP properly configured might still be vulnerable to malware execution. Here is how:
a) Assume that a buffer overflow exploit occurs and is not caught by DEP, etc.
b) The buffer overflow shellcode downloads an executable file with a nonstandard extension such as .tmp in a nonstandard location. C:\index.tmp would be an example.
c) ... <-QUOTE}

Limited users do not have the right to write files in the root of a volume, only folders.

[Cosmo 203]

{QUOTE-> actually me thinks limited user can get you infected for limited user files only but i may be wrong. <-QUOTE}
In principle you are correct, but more clearly you should say: only files, where the limited user has the writepermission, can get infected from a program (inclusive malware), that is executed with limited rights. That are; all files that have been created by this user or are stored inside the user's profile. So the system itself and all program files, that have been installed with admin rights are unchangeable by a limited user.

[Rmus]

{QUOTE-> b) The buffer overflow shellcode downloads an executable file with a nonstandard extension such as .tmp in a nonstandard location. C:\index.tmp would be an example. <-QUOTE}
{QUOTE-> Limited users do not have the right to write files in the root of a volume, only folders. <-QUOTE}

I just confirmed this.

200743
_______________________________________________________-

thanks,


----
rich

[tlu]

@rich: You can create a folder in c:\ with limited rights, but if you can save/create a file in c:\ then your files/folders permissions are obviously corrupted. You should apply step2 in this (http://www.wilderssecurity.com/showpost.php?p=1201866&postcount=146) post in order to restore the default permissions.

[Rmus]

Thanks, Thomas - I reset the permissions.

I edited my post above to confirm this.


----
rich

[Dogbiscuit]

{QUOTE-> actually me thinks limited user can get you infected for limited user files only but i may be wrong. <-QUOTE}
{QUOTE-> So the system itself and all program files, that have been installed with admin rights are unchangeable by a limited user. <-QUOTE}
I've seen the admin account become compromised when running under LUA (w/out SRP) on an updated system (with default permissions, etc.). So it is not far-fetched.

[MrBrian]

{QUOTE-> Small, but important correction (I set it bold here:)
<-QUOTE}

Thanks for the correction Cosmo 203. How about if c:\other\index.tmp, for example, had been used instead?

[MrBrian]

I don't want to duplicate information, so here's a relevant post (http://www.wilderssecurity.com/showpost.php?p=1263491&postcount=105) I made in another thread about how malware can execute or do further damage in a system using LUA and SRP.

[SpikeyB]

At work I am stuck with LUA. In order to run programmes of my choosing, I have created a folder off My Documents. In this folder I have a number of sub folders containing portable applications. I can also create shortcuts to these programmes in the startup folder of the menu system.

If I can run "unwanted" programmes in a LUA, then I see no reason why malware cannot and so I conclude that LUA is not enough.

If I was also saddled with the default rules for SRP then I would not be able to run my programmes.

[tlu]

{QUOTE-> At work I am stuck with LUA. In order to run programmes of my choosing, I have created a folder off My Documents. In this folder I have a number of sub folders containing portable applications. I can also create shortcuts to these programmes in the startup folder of the menu system.

If I can run "unwanted" programmes in a LUA, then I see no reason why malware cannot and so I conclude that LUA is not enough.

If I was also saddled with the default rules for SRP then I would not be able to run my programmes. <-QUOTE}

See post #93 (http://www.wilderssecurity.com/showpost.php?p=1262387&postcount=93).

[EASTER]

{QUOTE-> @Rmus: I think you misunderstood LUA. Its purpose is that you don't have write permission for the biggest part of the registry, for c:\Windows and c:\Program Files. That means that all critical parts of your system and your applications are protected against deletion/modification/manipulation without the need of a HIPS, and the unwanted installation of a driver or rootkit etc. is impossible. Nobody ever said that it isn't possible to install applications to other folders than the default c:\Program Files (since a limited user can create folders beneath, e.g., c:\ ) as long as they don't want to create/modify files somewhere in c:\windows or create/modify keys in, e.g., HKLM. It only means that these applications aren't protected against modification since the user has write permission to that folders.

Again, LUA alone doesn't imply an execution control. You can execute any application with limited rights but it isn't able to seriously harm your system. If you want execution control you have to combine it with SRP or an AE. <-QUOTE}

Good Point!

I see in addition to LUA for example thru the implimenting of the app SuRun coupled with hardening apps such as SAMURAI for one that one of it's features refuses to allow access to \Device\Physical Memory if i'm not mistaken but this is severe hardening or as i think Blue might put it another way, for a STATIC system in much the same way Deep Freeze and others would work.

I know it's been mentioned that LUA should repel enough as to not make neccessary a HIPS, but if you want to absolutely assure your LUA is "Rock Solid" against user-mode and potential howbeit tiny entryway exploit potential, a very "Lite" HIPS like EQS can serve to LOCK DOWN completely and CONFIRM that your LUA remains untouchable.

Again though, the purpose of LUA combined with SRP and some hardening should pretty much cover the spectrum relieving any need for HIPS, being a proponant of them i would test my LUA severely first to make sure no compromise is possible at all, and if it isn't, only then i would invite the services of a (once again) "Lite" HIPS to suppliment full containment.

You can see by my enthusiasm over them how effective i found them to be, but the ideal! method would be to operate with LUA without HIPS at all, in which i'm highly in favor of myself in spite of my encouragement from them.

More testing for me upcoming.

EASTER

[Rmus]

{QUOTE-> ----------
Originally Posted by tlu
@Rmus: I think you misunderstood LUA. <-QUOTE}For those just jumping into the thread at this point, you need to refer back to my posts #86 and #97 to get the context in which I tested an LUA: to see if it prevented the downloading/running of a program.

The answer is no, as I successfully downloaded to the desktop and ran a self-contained program.

My "misunderstanding" as tlu explained,

{QUOTE-> Nobody ever said that it isn't possible to install applications to other folders than the default c:\Program Files (since a limited user can create folders beneath, e.g., c:\ ) as long as they don't want to create/modify files somewhere in c:\windows or create/modify keys in, e.g., HKLM. <-QUOTE}Of course, I know that with Anti-Executable, the system is locked down completely so that no one but a person with the Password can install any executable - anywhere; but I was exploring what LUA alone provided. That's all.


----
rich

[wordman]

I think LUA is mostly focused on protecting you against drive by attacks and against malicious apps that don´t need to be installed. But some of this can also be achieved on an admin account with DMR/SRP. Of course LUA is the better approach.

[Dogbiscuit]

{QUOTE-> I think LUA is mostly focused on protecting you against drive by attacks and against malicious apps that don´t need to be installed. But some of this can also be achieved on an admin account with DMR/SRP. Of course LUA is the better approach. <-QUOTE}
{QUOTE-> I think LUA is mostly focused on protecting you against drive by attacks and against malicious apps that don´t need to be installed. But some of this can also be achieved on an admin account with DMR/SRP. Of course LUA is the better approach. <-QUOTE}
wordman, why did you copy this from post #54?

[SirMalware]

Recipe for MalwareFree Windows XP Pro

INGREDIENTS:
1 Windows XP Pro O/S w/updates
1 Hardware Router/Firewall

DIRECTIONS:
1. Turn on PC and preheat computer to 75 degrees F.
2. Add 1 cup Limited User Account.
3. Add 1 cup Software Restriction Policy.
5. Add 1/2 cup Designated File Types.
4. Stir in 1/2 cup Additional Rules.
5. Bake 3 hours in preheated, 450 degree F Broadband Internet.
6. While baking, turn browser occasionally making sure many rogue servers are cooked evenly.
7. After 3 hours, remove computer from broadband Internet and let cool.
8. Open enclosed black bag and sprinkle fresh, raw, undetected malware into computer and bring to boil.
9. Test freshly baked product by examining cooked O/S outside of the hard drive and look for any bitter malware infestations that would cause spoilage.

Now sit back and enjoy this delicious, protected MalwareFree XP Pro meal. All natural juices are sealed in without the possibility of any bitter taste entering. Just think, you'll be the envy of friends and the enemy of malware writers with your new cooking skills preparing this delightful XP Pro dish. And remember, there's nothing to buy or clean up afterwards, it's free! And it's made with all natural ingredients and no artificial software preservatives!

NOTE: In several taste tests, we found no need to add any extra antivirus or HIPS seasoning to this recipe as these didn't add any flavor or nutrition. We found the texture to be lighter and much smoother with a 'less is more' approach. Also, you can't add the Software Restriction Policy ingredient to the mix if you have Windows XP Home, Windows Vista Home Basic, or Windows Vista Home Premium. However, by adding 1 cup Limited User Account and 1 cup Fat-Free Third-Party HIPS to any of these, they will still taste delicious.

[MrBrian]

{QUOTE-> Funny and you do got a point, but I will try to explain it better: I´m saying that it would be cool if you could install apps inside LUA without the need to give them "full admin" rights. Because right now there is in fact no difference between installing apps in LUA or admin mode, the risk stays the same. So in order to make this plan work, LUA should be modified in a way that apps should have just enough rights to be able to modify only certain parts of the file system and registry.
<-QUOTE}

I found a quote from a person here (http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html) who modified permissions in XP to achieve this.
{QUOTE->
To get around this problem, e.g. on XP, I would normally just add appropriate permissions to my normal (restricted) user account, in such a way that this account would be able to add new directories under C:\Program Files and to add new keys under HKLM\Software (in most cases this is just enough), but still would not be able to modify any global files nor registry keys nor, heaven forbid, to load drivers. More paranoid people could chose to create a separate account, called e.g. installer and use it to install most of the applications. Of course, the real life is not that beautiful and you sometimes need to play a bit with regmon to tweak the permissions, but, in general it works for majority of applications and I have been successfully using this approach for years now on my XP box.
<-QUOTE}

[MrBrian]

Here are some Vista-specific quotes from the co-writer of a book on Vista security, taken from http://msinfluentials.com/blogs/jesper/archive/2007/03/01/confusion-about-vista-features-what-uac-really-is.aspx:

{QUOTE->
UAC does not, nor is it intended to, stop malware.

UAC's purpose is to enable more users to run as a standard user.
<-QUOTE}

{QUOTE->
An elevated application runs on the same desktop as a low (non-elevated) application. Windows, just like other operating systems, do not implement complete process isolation between applications on the same desktop. This means that there are certainly ways for a low application to impact what an elevated application can do. There is no security boundary that isolates processes on the same desktop. The OS does include some protective measures to keep the obvious, and unnecessary, avenues of communication blocked, but it would be impossible, and undesirable, to block all. Therefore, Microsoft does not want to consider breaches of that - nonexistent - boundary as security breaches.
<-QUOTE}

{QUOTE->
In the book, I laid out the increasing order of security of different ways to become an administrator:

Good: Run in admin-approval mode
Better: Run as standard user and elevate to separate admin account
Best: Run as standard user and switch user to a separate admin account instead of using UAC to elevate <-QUOTE}

[Rmus]

Thanks for that link to the blog on Vista.

{QUOTE-> UAC does not, nor is it intended to, stop malware. <-QUOTE}This statement needs some clarification and amplification, for it depends on what you mean by "stop."

The author seems to be investigating "stop" as this:

{QUOTE-> ... stop malware that is executing on your system from elevating to an administrator and taking over your system. <-QUOTE}But for many people, "stop" means preventing the malware from executing in the first place. This means that the security protection should alert to any attempt to do so.

I use the term "unauthorized executable" rather than malware. I define that as

Any executable not already installed on the computer.

In this case, Vista's UAC does very well. I asked two people to test, and in every case, an attempt to install something brings up an alert similar to this, where the user inserted an installation CD which used the autorun.inf file to automatically run the setup file:


201341
____________________________________________________________________

In another case, a similar alert displayed when a USB drive with an autorun.inf file attempted to automatically install an executable.

This means that Vista's UAC will alert to the remote code execution exploits such as the drive-by download and the USB autorun.inf methods (Pendrive, digital picture frame) to install an executable.

In this situation of "stopping malware," UAC performs very well. It's too bad that this point is not brought out in discussions of Vista's UAC.

--

[MrBrian]

I have found some research that shows a way that code running as a limited user in Vista can piggyback itself onto other programs that the user runs elevated. Microsoft was contacted, and responded that this is not considered a privilege escalation exploit and therefore will not be fixed.

SRP with proper settings will prevent this from happening.

[Rasheed187]

{QUOTE-> I found a quote from a person here who modified permissions in XP to achieve this. <-QUOTE}

Hi MrBrian,

I also read it a while ago, and it was funny to see that a bigtime security expert agreed with me, and also found this to be very odd! I mean how on earth can you give just any tool admin rights? That´s just silly. :)

[ParadigmShift]

Software Restriction Policy with added Designated File Types and Additional Rules

Free, Easy, Simple, Secure, Stable, Lightweight and best of all, it works. :)

[ParadigmShift]

No install...
No bugs...
No crashes...
No hooks...
No fees...
No English translation...
No malware infiltration...

Just a protected operating system and wonderful peace of mind.

(Sung to the Sominex tune)
Take SRP tonight and sleep...safe and restful, sleep, sleep, sleep.