Is Limited User Account enough? Not really...

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

 

@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?

 

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.

 

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.

 

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).

 

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



soldataq

 

Small, but important correction (I set it bold here

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

 

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.

 

I just confirmed this.


_______________________________________________________-

thanks,


----
rich

 

@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 post in order to restore the default permissions.

 

Thanks, Thomas - I reset the permissions.

I edited my post above to confirm this.


----
rich

 

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.

 

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

 

I don't want to duplicate information, so here's a relevant post I made in another thread about how malware can execute or do further damage in a system using LUA and SRP.

 

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.

 

See post #93.

 

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

 

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,

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

 

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.

 

wordman, why did you copy this from post #54?

 

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.

 

I found a quote from a person here who modified permissions in XP to achieve this.

 

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

 

Thanks for that link to the blog on Vista.

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:

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:



____________________________________________________________________

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.

--

 

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.