-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
XP SP2 Security Center insecure and already spoof'd
- Thread starter Phoenix
- Start date
- Status
This is being blown out of proportion. If I understand it correctly, it does not make you system more vulnerable. It just means that some of the protection SP2 adds can be negated if a program is run on your system. But if you have a malicious program run on your system you are owned anyway, regardless of SP2 or not.
Lord Error
Insane For Sony
Yeah, that's my understanding as well after reading the EETimes article, BUT, if you just do to that mikx.de site linked above, the guy claims that he made the web page that installs some EXE into your startup folder just by dragging the scrollbar... That's an amazingly huge security issue.
clipunderground
Member
Marconelly said:
uh oh... thats not good.
Two different issues.
This only works if you're admin. If you're admin, someone could screw up your system in a million number of ways more subtle and useful than spoofing the security center.
Grasping at straws.
This on the other hand is real and does suck. The easiest work-around for this is to turn off Binary and Script Behaviors in the security zones config.
Phoenix said:
This only works if you're admin. If you're admin, someone could screw up your system in a million number of ways more subtle and useful than spoofing the security center.
Grasping at straws.
This on the other hand is real and does suck. The easiest work-around for this is to turn off Binary and Script Behaviors in the security zones config.
Particle Physicist
between a quark and a baryon
Marconelly said:
that happened on my SP1 . :/
Error Macro
Member
Dammit! How do you delete the booom[1].exe file from the Startup folder? I've tried unchecking it in msconfig, rebooting, still there. I tried booting into safe mode, but then it doesn't show up in the startup directory. WTF.
Phoenix said:
The point is the Security Center "spoof" relies on the fact that you're running as admin.
If you're running as admin, there is no way the Security Center can stop you from "spoofing" it via WMI, or any other means.
As an attacker, I could just "install" a "fake" AV scanner.
Hell, I could install a driver that intercepts scan attempts from an AV filter you have installed.
Or I could just put a whole damn rootkit onto your machine, and the OS itself would be none-the-wiser.
The fact that you can tamper with the Security Center as an admin means basically zilch. Like I said, grasping at straws.
If you run hostile code as an admin, you've already lost, and it doesn't matter if you're running Linux, BSD, or MacOSX.
Windows provides ways to run as a regular user... try shift-right clicking any icon in the start menu. You will see a "Run As..." option that will let you authenticate as admin for the apps that need it.
So it's not like you can't run as a regular user.
Error Macro
Member
SKluck said:
YOU CHEATED! NO FAIR!
But fuck me, I still can't get rid of this file. HELP ME OBI-WAN KENOBI
Phoenix
Member
aaaaa0 said:
Or that you trust ActiveX controls - which can compromise your system regardless of who you're logged in as. The problem is that WMI is an open interface for any program running and those programs don't need admin rights to access the WMI (just to change it). The same way malware and spyware end up on systems via the internet provides ample opportunity for a remote application to compromise the WMI. As has been observed and documented, the security center is actually shut down during several upgrade style operations at which time any malware which can query the WMI (without iliciting any error) can do whatever they like because they know its down.
It also would have been nice if the system that is supposed to secure your OS wasn't waved in front of would-be attackers and script kiddies
I just went into my systems library directory on OS X and tried to remove libraries and the OS denied me permissions because you have to at a minimum sudo the command or actually login as root. My user, however, has admin permissions on this box - so that's not true.
Next the BSD kernel will require a dialog to pop-up when any untrusted (i.e. not installed) application attempts to write or read from system protected files If you're just using your machine and a dialog pops up asking you for your username and password - would you enter it?
So no - OS X in particular would currently not be vulnerable to this type of exploit. It also wouldn't be vulnerable to the startup exploit listed earlier because that too requires root or admin priviledges and will result in a dialog box popping up asking for permissions... and require a browser with exploitable internet zone configurations (which is the exclusive domain of IE at the moment).
Finally you mention that a user of the Home edition (which runs by default in Administrator mode - *sigh*) can use the run as in order to make their programs run as another user. Few things with this:
1) Go ask your mom how to run programs as another user, and maybe the secretary at your job. Right - the average person just double clicks on applications.
2) By default, the vast majority of default installs of the home edition (mom and pop) are already running in EXACTLY the configuration you're saying is not a big deal. it would be different if the default 'unattended install' didn't leave the OS exploitable from installation.
Me said:
Phoenix said:
First of all, ActiveX controls have nothing to do with this exploit. An ActiveX control running as a non-admin user will not have access to change WMI.
Seriously, ActiveX controls are no different than browser plugins. They're just programs that talk to a couple COM interfaces instead of browser proprietary plugin interfaces. They are not some magical kind of executable that can bypass security.
It's like saying downloading the Macromedia Flash mozilla plugin and installing it can compromise you no matter who you're logged in as. Well DUH.
The only difference is that you can install an ActiveX control without closing your browser and running an external setup program.
But as of SP2, there are several layers of dialogs preventing you from clicking yes, AND IE automatically refuses ActiveX installers unless you explicitly go to the info bar and allow it.
Have you even used WMI?
What's different about having access to WMI than, say, having access to CreateFile(). Or RegCreateKey(). Or (gasp) CreateService()?
WMI is just another way to get at OS services, it's no different than having access to Win32.
WMI is not some magical "backdoor" into the OS.
If you're admin, you can change anything you want, including WMI, drivers, disk configuration. Hell you could open \\.\PhysicalDisk0 and party on the hard disk sectors directly.
How's that for bypassing security?
On the other hand, if you're not an admin, you can't do any of the above, and you shouldn't be able to modify the WMI parameters that control the security center either -- which renders this whole discussion about "spoofing" the security center moot.
So what? There are plenty of ways to monitor for security programs that don't involve querying WMI.
For example, something as simple as asking the system for a list of processes. This is not blocked by any firewall or antivirus app I know of. Things like task manager do it all the time.
You could easily probe to see if a particular driver is loaded without WMI, without setting off any alarms either.
The WMI thing is a complete red herring.
It isn't, if you're not an admin.
An "admin" is "a user with the Administrators SID in his primary token" in Windows, or "root" in Unix.
If you have to re-authenticate to the system to do something, then your actual security context is not as an admin, as defined above.
And hey, that is a smart design, don't get me wrong. But that's not significantly different than running as a regular user in Windows, and using "Run As..." to launch the control panel.
On a different note, there is a way to create something called a "Restricted Token" in Windows, that logs you in as a particular user, but with privileges disabled.
This could be used to lauch programs in sandboxes, so that you could log in as a true admin, and run all your programs as weaker versions of yourself.
Sadly there is no support in the GUI for this.
http://msdn.microsoft.com/library/d...s/secauthz/security/createrestrictedtoken.asp
Yes, the lack of a UI for this features is a bad thing, and yes I agree it's something that MS should add to the UI.
The vast majority of apps will NOT require admin on Windows, if you set them up properly.
For the minority of apps that DO require admin, you can use "Run As...". My Mom is unlikely to use any of those apps, just like your Mom is unlikely to type the root password in to your Mac.
Yes, and this IS a bad thing, but too many people don't even want passwords on their accounts, let alone having to reauthenticate themselves whenever they want to open something in the control panel or system configuration.
Phoenix
Member
aaaaa0 said:
The exploit is actually two fold:
1) If you are an admin user (like most XP Home Edition users) then you are 'pre-owned'.
2) If you aren't an admin user then ActiveX controls installed or RUNNING FROM the web can peep the settings. ActiveX controls (malware, worms, etc) running locally can actually change the status flags such that regular users would think their machine is secure when it isn't (this actually being the real issue in the exploit).
Actually they are different in some ways that aren't necessary to go into here - particularly if you've written them using C#. Unlike generally sanboxed browser plugins - well, on browsers than IE anyways, ActiveX plugins have the ability to execute arbitrary native code. I used to write OpenGL renderers in ActiveX so I'm well aware of how to get past the browsers security mechanisms using them. So yes, they can bypass security in so much as they can load up opengl32.dll toss a malloc'd 1024 byte vertex array into glDrawElements and buffer overflow the dll and bypass the security layer altogether. They can do this WITHOUT being admin. That's always been the problem with ActiveX controls, .Net, etc. If you're gong to allow me free native library access to a library on the machine OR one that I provide / I can root you till the end of time.
Yes - and since it so obvious then the consequences are JUST as obvious. Sandbox all ActiveX controls and bar them from getting to the native system just like java applets.
Yes - I have a subscription to MSDN like every other decent I/T developer in the world
Thats like me asking you if you've ever written an ActiveX control. The ramifications of anything affecting the internet connectivity of Windows is generally well within my domain and responsibility for knowing.Expedience and intent. If I intend to turn your machine into a spam relay - I want you to believe that your machine is fine and up-to-date at all times. I don't want to create a condition/environment that antivirus software would recognize. If you recall, last week there was a gaf'er asking how to ensure that their machine was up-to-date. For XPSP2 the answer would have been 'check the security center.' Does the problem become a little more apparent now?
WMI isn't really a mechanism for accessing OS services and obviously isn't a backdoor. What it is however is a way to deceive users and to make the security center meritless for the user because while they think their machine is fine - it isn't... it is a compromised box. The security center must absolutely and at all times be running, be secure, and have its internal data encrypted (for goodness sakes) so that a user can know the condition of the machine.
We've already gone over this. By default XP Home has users AS admins.
There is a different in the Unix domain between having administrative rights and having root access. The way Windows currently handles permissions (and hopefully this is fixed in Longhorn), admins are the equivalent of root users - which is an incorrect behavior. The rights granularities for home users of XP isn't granular enough which is the reason why XP Home installs in default as Administrator in the first place (according to a WinHEC almost 5 years ago). There are many things (like installing software) that the Home user would want to do that because of the funky access layer really belong to Windows admins under the NT kernal and NTFS.
We've been over this. Find users that have actual regular user accounts and ask them how they would run as Administrator. I will guarantee you that most average computer users in both the wild (home users) and in corporations don't know about Run As, the later relying on actual system admins to handle the tasks that Run As are used for and the former mostly running in Admin already.
This is what they were supposed to do in XP and I assume what the will be doing in longhorn.
The difference being one of accessibility/usability. If my Mom (if she ever really started using computers) tried to do something on the Mac that required a priviledge elevation, it would ask her for a password. If your mom did similar on Windows, the operation would fail and tell her she didn't have Administrator priviledges. From a usability perspective they are very different from each other.
But if you're going to leave the system in an immediately exploitable state - who are you doing a favor? The guy who is taking his rooted windows box into bestbuy or compusa so they can fix it at $50/hour? The users who look into other products because they keep hearing in the news how the OS they are using is a securty problem? The press who dig at your product everytime one of these issues come up?
Users working at most companies in the world are used to logging into their computers - hell you've already gone through the hassle of putting in Fast User Switching. Lock down the system, don't allow people to just be administrator and make them actually go through a process to bring the machine into administrator state - and only in a temporary sudo like manner. If you give the average user a choice between doing things quick and easy or slower and sometimes painful, they are goin to go the quick and easy route because they don't expect anything to happen to them.
Phoenix said:
Agreed. If anything hostile gets on your system, you're screwed. There's nothing the OS can do to stop that if you insist on running as an admin.
ActiveX controls running locally as ANY user can change the settings? I find that extremely hard to believe.
An ActiveX control is JUST a DLL that exports a couple COM interfaces. It's nothing special. If a non-admin regular EXE can't modify the WMI flags, why should an ActiveX control running as a non-admin be able to do it?
C# who cares.
Managed code is just a wrapper around the real stuff underneath for people who dont understand or dont want to deal with it.The basic way an ActiveX works is the same regardless of language.
You have a DLL that implements some standardized COM interfaces, and a DllRegisterServer() entry point that sticks a couple registry entries in the right places. When an app wants to use the ActiveX, it tells COM to create an instance of the interface. COM looks up the interface in the registry, loads DLL into memory, and calls DllGetClassObject() on that DLL, causing the object implementing the interface to be constructed. COM then returns the requested interface pointer to the app.
All regular browser plugins are written as native code, there is NO sandbox. There is no sandbox in mozilla for plugins. There is no sandbox in Firefox for plugins.
Go download Macromedia Flash for Mozilla. It's a regular DLL. Go download Quicktime. Native code. If these developers wanted, they can do anything on the machine you can. Pop dialogs, spawn processes, anything. The browser does NOTHING to stop them, because it cant.
There IS no security layer in the browser in a plugin. None. The browser doesnt even try to enforce one. You can LoadLibrary() on any DLL you want, call any function you want. You can do anything an EXE can. You dont need to buffer overflow anything to break out of the browser.
Browser plugins are exactly the same way.
The Flash plug-in has had a number of holes that could result in a remote exploit because of this, and a remote rooting, if you were running as a privileged user.
As a side point, .NET is different. .NET is a managed runtime like Java. You cannot freely access native libraries from a managed .NET class within the browser CLR without the correct permissions. If you have done any development with .NET CLR or managed code, youd know this.
There is no way to sandbox native code without creating a separate process running under a different primary token (like how Apache and IIS6.0 do it). Since both ActiveX controls and browser plugins are all loaded in-process and are all native code (this is true of all browsers, including Firefox, mozilla, Opera, and IE), there is no security model beyond what the OS provides at the browser process/user level.
ActiveX and Java applets are two different things.
The analogue for an ActiveX is the browser plug-in. You write native code modules, which plug into the browser directly. There is no browser security model to speak of. You have to trust your browser plug-ins, just like you have to trust your ActiveX controls.
Like browser plug-ins, you are not supposed to install ActiveX controls very often. Like browser plus-ins, you tend to install a couple when you first start browsing (QuickTime, Flash, Acrobat, maybe RealPlayer or Java, etc), but after a while, its pretty rare that a website should legitimately ask for one to be installed.
UNLIKE browser plug-ins, ActiveX controls all have to be cryptographically signed, and this is verified by the browser before the plug-in is installed. The signature is intended to provide accountability and a guarantee that the installer package has not been tampered with since it was created.
UNLIKE browser plug-ins, ActiveX controls can be installed without exiting the browser, or running an external setup program. HOWEVER as of SP2, IE will first refuse to download the installer package automatically, until the user explicitly requests it by clicking on the information bar and clicking download. Then the user must explicitly click yes on the following "are you sure" dialog to allow IE to download the file, and finally, he must click yes one last time on the "signature verification" dialog to allow IE to unpack and install the control.
An analogue for .NET/Java applets would be Macromedia Flash .swf files. You write little applets, which execute in the context of a protected environment provided by a browser plug-in (the .NET CLR, Java VM, or the Flash plug-in).
Hence, making ActiveX into Java is a nonsensical proposition. Theyre two DIFFERENT technologies, intended for two DIFFERENT tasks. Apples and oranges.
Yes - I have a subscription to MSDN like every other decent I/T developer in the world
Pop quiz:
What is a .MOF file?
What are three things an IT administrator might do with WMI?
Where is the WMI database actually stored?
If I have owned your machine to the point where I can install a spam relay onto your machine, I can shut up the security center with two commands:
sc stop wscsvc
sc config wscsvc start= disabled
I dont need to screw around with WMI.
Frankly if the machine is that owned, Id just install a rootkit, and not even your antivirus will catch me then.
The whole WMI thing is a red herring. If the machine is owned to the point I can do stuff to WMI, I don't need WMI to do far worse stuff.
It sure is a way to access OS services.
POP QUIZ:
What is a WMI provider, and why would I want to write one?
Thats like saying a web browser is just a delivery mechanism for exploits.
I could just stop the security center, and put in my own fake security center app.
The security center UI is just an application that displays a dialog and some pop-up balloons. It runs in your user context with no special permissions.
It is a useful advisor to the state of an uncompromised system: you can get all your notifications in one place, as opposed to three different apps.
If a machine has been compromised, if you've been running as admin, all bets are off.
If you haven't been running as admin, the state of WMI hasn't been corrupted anyway, so the security center "spoof" is irrelevent.
Semantics. Admins are always root users.
What Windows should be doing is forcing everyone to log-in as regular users.
Regular users should have the ability to elevate themselves to admin for specific tasks by authenticating themselves to the system again.
Wait, that's what you can do today (except for the "force" part). OMGWTF.
The XP security model is plenty granular enough. Have you ever actually taken a look at it? (Please, ignore the dumbed down UI pasted on top of it in Home Edition.)
What are not granular enough are the rights that apps request in order to run properly.
This is not something MS can change with a service pack.
Good point, though superficial.
Given a quick explanation, theyll learn the correct response is to try Run As if theyre sure they want to do what theyre trying to do (which shouldnt be that often to begin with).
Like I said above, the main point is XP unfortunately has no formalized notion of a "special user that can elevate privileges by authenticating to the system", and yes this is a deficiency, though you can substitue a regular user with "Run As..." to get close.
Further improving this is not something that could be done in a service pack IMHO, and not without breaking tons more apps then SP2 broke already.
It sucks, but people really dont want to remember passwords.
BTW, the system does its best to prevent people that insist on having password-less accounts from screwing the system. The policy for XP Home is that all accounts with no passwords cannot be used for inbound network access. IE, you cant connect to an XP Home machine over the network with an account that has no password, you can only do a local console logon with such an account.
Frankly I think the only real solution to the whole logon problem is some sort of biometric/smartcard id and some sort of mnemonic PIN.
Example: Put your thumb here, and click the 3 photos out of 20 on the screen that you recognize as your pass-code. (Ex: a dog, my friend Joe, an airplane).
Guys, guys. There's no need for a 50 page discussion here. You KNOW Microsoft is going to release a patch for this. Keep your eye on windowsupdate for the next couple months.
I LIKE SP2, dammit. My comp starts up a little faster, it seems to handle memory a lot more efficently, games run better... overall everything is just better. If it goes too slow for you, slipstream it, reformat and start over.
I LIKE SP2, dammit. My comp starts up a little faster, it seems to handle memory a lot more efficently, games run better... overall everything is just better. If it goes too slow for you, slipstream it, reformat and start over.
Phoenix
Member
aaaaa0 said:
Reason 1)
http://secunia.com/advisories/10066/?show_all_related=1
Note this isn't the only one of this sort. Most worms and the like use privlege escalation holes like this/ Just because you are running as non-admin doesn't mean that an ActiveX can't use something that escalates its privlege in a busted manner.
Reason 2)
ActiveX controls can load native code and through overflows can and do bypass the security handler of the OS. Where do you think all these exploits are coming from? They aren't going through the normal Win32 API!
Reason 3)
Sign your code with Authenticode. CHeck the security settings in Internet Options for the Internet Zone and see whether or not your code will run. Check your "Run ActiveX controls and plug-ins" setting - is it set to Enable or Administrator approved.
C# who cares.
The basic way an ActiveX works is the same regardless of language.
Actually - they are particularly different in the way memory is accessed. While its still 'possible' to overrun stuff in the CLR, its much much much harder. 99.9% of exploits come from memory management or thunking errors.
You do if you want to grant yourself new privleges.
See C# comments above. Now, how many C/C++ applications do you know and how many C# ones do you know.
They are not intended for different tasks. A Java applet can do 100% of the things an ActiveX control can do.
An intermediate human readable file used by WMI/WBEM before being turned into native OS classes.
See WBEM.
Good question. Dunno. Never tried to find out.
Rootkit is actually pretty easy to find - you just don't do it through antivirus software.
The point that you're not getting is that the point is NOT to do far worse, its to leave your machine exploited in a way that the user would think its okay.
Our survey says *engh*. Priviledged operations in WMI requires that the user already have the rights. You can't add rights through WMI. Or perhaps we're misunderstand each others intent. The piggyback to your pop quiz is answer through this same line. A WMI provider is the WMI registry equivalent of a webservice endpoint and goes hand in hand with the MOF files we were talking about earlier.
Indeed. But to call this 'grasping at straws' which most XP Home machines out there ARE running as admin is the same type of thinking that has brought us to this point in Microsoft.
Only in Windows. I'm an admin in OSX but I am not root - not even close.
Right, except for the only part that makes security relevant. OMGLOL.
They used this excuse when going to Windows 2000, and XP, and I just hope they don't use this excuse for Longhorn. You either want a secure OS or you don't. If you do, then there are going to be some people that are going to have to change their way of working, the same way DOS game writers had to get used to not having arbitrary access to memory when they moved to WIndows.
Or they could force people to be regular users and then require them to sudo their privleged operations. No point in bringing in a hardware solution when a software one is readily available. People have to use passwords ALL THE TIME so I'm not sure what the 'added hassle' is. Heck you had to enter a password on GAF to post this post! Passport was supposed to be a mechanism to manage these trust relationships, but that initiative has kinda died out.
so should my standard way of working be as a non admin?
So I set up another account and log into that, then become an admin if I specifically want to install something?
Will that stop it automatically logging in though? Its very handy for my wife for it to log in automatically, which is why I've always just had one account.
So I set up another account and log into that, then become an admin if I specifically want to install something?
Will that stop it automatically logging in though? Its very handy for my wife for it to log in automatically, which is why I've always just had one account.
Phoenix said:
Did you read the exploit or not?
That exploit depends on WHERE hhctrl.ocx is instantiated.
The problem is a high privilege app (ie running as a high privilege user) instantiating hhctrl.ocx, where a low privilege user can manipulate it.
This is no different than a high privilege app (ie running as a high privilege user) stupidly launching notepad with CreateProcess() instead of CreateProcessAsUser( THE_LOW_PRIVILEGED_USER), and allowing the low privileged user to (just for example), use File->Open.
All this exploit demonstrates is that high privileged apps need to be careful about what they expose to low-privilege users to manipulate. Woooo.
Didn't we just get through a post where I explained ActiveX controls are just like EXEs in that they start with whatever privileges the user that started them had?
Yes, there is a bug in that hhctrl.ocx should be further dropping its own privileges regardless of who started it, BUT that's not a problem with "ActiveX", it's a problem with hhctrl.ocx.
ActiveX controls USE the normal Win32 API to do everything!
Code:
C:\WINDOWS\system32>link /dump /imports hhctrl.ocx
Microsoft (R) COFF/PE Dumper
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file hhctrl.ocx
File Type: DLL
Section contains the following imports:
KERNEL32.dll
5D30114C Import Address Table
5D364044 Import Name Table
0 time date stamp
0 Index of first forwarder reference
40 CopyFileA
393 WinExec
1B5 GetShortPathNameW
252 LoadLibraryW
259 LocalFree
141 GetCurrentProcess
144 GetCurrentThread
48 CreateDirectoryA
CC FindClose
173 GetLocaleInfoA
318 SetFilePointer
3BC lstrcmpA
23C IsValidCodePage
316 SetFileAttributesA
165 GetFileType
1B4 GetShortPathNameA
B6 ExitProcess
[
etc
]To sign your code you need a certificate. Your certificate has to be trusted for IE to install your ActiveX component. IE only trusts (by default) certificates endorsed by one of the public certificate authorities.
So if I sign my ActiveX install package with a certificate I generated myself using my own certificate authority, IE will not trust it on your machine, and hence will not install it. (or only after you explicitly override IE and tell it to install it).
The certificate does not guarantee the ActiveX control is safe, but it guarantees that the person possessing the certificate signed it and that the contents havent been tampered with since it was signed.
Yes it is much harder to overrun in C#.
But were talking about ActiveX controls. Which are written in any language that lets you invoke COM, and which run as native code with the permissions of that user.
Even in C# if youve been granted the right CLR permissions you can declare the unsafe keyword to get access to pointers and native methods.
Me said:
Phoenix said:
You don't need to if youre writing a native code browser plugin. Just call CreateProcess() and youve broken free of the browser. The browser HAS no plugin security model, because it cant enforce anything.
You cant, however, get any more privileges than the user running you, because the OS enforces privilege at the user level.
Me said:
Phoenix said:
What is your point?
Me said:
Phoenix said:
No, it cant.
How do you think the Sun JRE plugin is implemented in IE?
Heres a hint: its not written in Java.
Code:
Y:\Program Files\Java\j2re1.4.2_05\bin>link /dump /exports NPJPI142_05.dll
Microsoft (R) COFF/PE Dumper
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file NPJPI142_05.dll
File Type: DLL
Section contains the following exports for npJava.dll
00000000 characteristics
40C0029A time date stamp Thu Jun 03 22:03:22 2004
0.00 version
1 ordinal base
11 number of functions
11 number of names
ordinal hint RVA name
8 0 000018F6 DllCanUnloadNow
[b] 9 1 000018FA DllGetClassObject <------------------------ *** [/b]
10 2 00001A82 DllRegisterServer
11 3 00001BBB DllUnregisterServer
1 4 000011B5 NP_GetEntryPoints
2 5 0000122A NP_Initialize
3 6 0000127A NP_Shutdown
4 7 00005DAC NSCanUnload
5 8 00005CE7 NSGetFactory
6 9 00005DEE NSRegisterSelf
7 A 00005E3A NSUnregisterSelf
Summary
1000 .data
2000 .rdata
1000 .reloc
5000 .rsrc
6000 .textNow you can't very well get rid of ActiveX if Java is implemented as one now, can you?
The point is ActiveX is not Java, and if Java could do everything ActiveX could, then why is the Java plug-in implemented as an ActiveX? Hmmm?
Great. Now for full points, tell me why they exist?
Zero. Give a concrete example.
Zero. Youre not even trying.
Harder to find than someone tampering with WMI. A good rootkit will install drivers and patch the kernel so you cant see the processes, files, and network activity of the rootkit itself. Nothing ON the machine itself will be able to detect that the rootkit has been installed. You have to shut down the machine and do an offline scan from a different instance of an OS to detect it. OR sniff the network traffic from a different machine.
And a rootkit will do that more reliably than tampering with WMI.
No points. Doesnt explain why Id want to write a WMI provider. Give a concrete example. There a hundred examples in Windows for you to look at if you want.
Im calling it grasping at straws, because its not that useful an exploit. Its much easier to just do something even more subtle, hard to detect, and USEFUL to the attacker.
We already went over this.
In OSX, the OS is calling you an admin, but its lying. Youre actually not an admin, until you reauthenticate to the system to do a privileged operation, at which point you temporarily get the powers of an admin.
Ive already said this is a really smart design, which can be emulated in XP by logging in as a regular user, and using Run As to run only certain things as admin (like control panels, etc).
And the point is yes, XP doesnt promote this usage pattern (it SHOULD), and yes, the usability isnt as good as OSX (which should be fixed in the future). But none of this could be changed in a service pack without breaking tons more apps than SP2 already did.
Sudo = Run As . Same thing.
Theres even a runas.exe in the XP commandline if you want to do the same thing via the shell.
I bet most people dont enter a password to get into GAF. They just ask GAF to put a cookie in their browser.
mrklaw said:
That's the idea. Create a regular user, and use that for as much as you can. Only go to admin when something doesn't work, you need to change the way the machine is setup, or you need to install software.
That means if you accidently run hostile code, it will be much less likely to take over your machine and/or corrupt the OS.
Yes, that will unfortunately stop the system from logging in automatically. And it will break some programs that always assume you're running as an admin.
Hmm, I will say that I've noticed that SP2 is a bit more sensitive to programs and their priorties. Unless I use DirectSound with hardware acceleration in Winamp, audio playback skips if I do something as simple as type a sentence in this post box. It didn't do that before. Now I can't use my gapless plugin, or WaveOut, or anything else. Doesn't matter what I set the buffer at or what the priority is.
The funny thing is it has improved performance for just about everything else. If a stupid audio plugin or two do not work, oh well. If I notice anything else I may start to get annoyed, though.
The funny thing is it has improved performance for just about everything else. If a stupid audio plugin or two do not work, oh well. If I notice anything else I may start to get annoyed, though.
Diablos said:
Incidentally, there was a huge security hole found in Winamp recently, you might want to see if they've patched it. It has to do with Winamp not restricting skin files properly.
http://secunia.com/advisories/12381
I believe it doesn't affect SP2, but you should upgrade WinAmp when the patch comes out.
Phoenix
Member
aaaaa0 said:
A java applet can do anything any other plugin can and through JNI can do everything an activex control can do. The JVM is written in C++ with chunks of C code.
Expedience and lack of reliance on already patented methodologies for writing browser plugins. That is EXACTLY why the Sun Java plugin is written as an activex control for IE and as a regular browser plugin for netscape and all other browsers.
I have no idea how to answer 'why' a file format exists.
I'm not about to go into an explanation of enterprise management or machine management. WMI providers allow you to get information about OS services. WMI is Microsofts implementation of WBEM.
Never tried to find out as it wasn't necessary for me to know. I could scour MSDN and actually find the answer to the question - was that what you were looking for? I'm answering these questions based on the knowledge I already have of the subject.
okay. Well if you think that installing rootkit is the only thing useful to an attacker, then clearly we are aware of totally different types of attackers.
Incorrect. In OSX admins have the natural ability to administer parts of the OS, change a variety of settings, etc - but they do NOT have root access and anything that would compromise system files requires privlege escalation. Root != admin != regular users in OSX. A regular user in an OSX environment cannot change any of the system settings - they will all show up with little locks next to them. Admins will have access to change all of these settings, but are still not root. Group admin is not the same as group root.
Phoenix
Member
For Internet explorer it has been and probably always will be ActiveX, COM, DCOM, .Net or whatever the technology is called this week. Sun uses ActiveX in Explorer for the same reason that they use DirectX for the rasterization of Java controls (though the unified graphics pipeline of 1.5->1.6 looks to finally move this to OpenGL), it is the fastest path to getting things done in Windows - it requires no additional work by the developer, and it opens no patent disputes because you're using someone elses tech as opposed to writing your own.
Phoenix said:
As soon as you allow JNI, you have to have a native library installed on the system to handle the calls from within Java VM.
If I install your native component, then the integrity of my JVM is toast if your native library is hostile.
How do you propose I decide whether or not I can trust your JNI native library?
As soon as you introduce native libraries, you introduce all the issues with native plug-ins and ActiveX controls.
Wow, youre finally getting close to the reason ActiveX exists and why Java cant do everything ActiveX can.
Remember you said:
Phoenix said:
Let me summarize, and make my point crystal clear:
Java applets are mobile code that executes in the context of a JVM. They cant do anything beyond what is supported by the JVM or the native libraries installed in the JVM environment through JNI.
ActiveX is an installation packager technology and an interface by which the browser can talk to native components that extend it, be they plugins that play movies, JVMs that implement Java, or dancing mouse pointers. More generally, it is derived from a generic communication mechanism (COM) by which ANY TWO binary components in Windows can talk to each other through well defined and agreed upon interfaces.
The proper analog for ActiveX in IE is the Netscape Plug-in interface. The proper analog for an ActiveX control in IE is a Netscape Plug-in. NOT A JAVA APPLET.
ANY extensible browser has to have some sort of binary interface defined for plug-ins to talk to. IEs just happens to be ActiveX (which is based on COM which is what the rest of the system uses), and Netscapes just happens to be one they rolled themselves.
They are equivalent methods of doing the same thing, hence why the same JVM plug-in DLL exports entry points for ActiveX for IE, and exports entry points for the Netscape for its plug-in interface. If you bothered to look at my exports dump above, that would be obvious.
Therefore you cannot argue that everything you can do with ActiveX you do with Java. Without ActiveX there would be no way to talk to IE, and the JVM would be unable to do anything with the browser.
ActiveX and Java are not equivalent, and they do not do the same thing.
Clear now?
File formats are invented for a reason. It should be obvious why MOF files exist from their contents if you know why WMI exists.
It does a lot more than just let you get information about OS services. Maybe if you actually used WMI youd know this.
Before you go spouting off about problems with it, it would generally behoove you to at least have a cursory understanding of what the thing actually is and what its used for.
No, Im saying if Im the attacker, Im going for the rootkit first. Theres no way Im going to screw around with WMI if I can rootkit your machine instead. Its like robbing a bank, and stopping to steal some gumballs from the vending machine on the way out. Its liable to get you caught, and doesnt buy you much to begin with.
Someone without admin privileges enabled is not an admin no matter what the OS decides to call them. You can call yourself an owner, an Administrator, or a power user, root it doesnt matter. If at that instant you do not actually have the admin privileges without re-authenticating to the system, you are not an admin.
Phoenix said:
ActiveX = COM + some predefined interfaces + a packaging and installer technology.
COM = binary standard for communication between different modules of code.
DCOM = standard for communcation between different modules of code over a network.
.NET = a standard set of language neutral runtime libraries and a managed runtime environment.
Sun uses ActiveX in IE because the Netscape-plugin interface in IE has been deprecated since IE 5.5 SP2.
There is currently no other way to write an IE native plug-in.
Phoenix
Member
aaaaa0 said:
The same way we do it for the Java gaming libraries under webstart. The native libraries are packed seperately. The core system is signed by Sun and as soon as a webstart application ties to load a native library it isn't accepted as is the case with an Active X control, the user is prompted with granular permission for allowing the load of a native library. This library is signed seperate from the webstart application. So if JOGL (Java OpenGL binding) comes up and you have no idea what it does - you know what's going on and can block it. Now, how does the user decide? Therein lies the problem and the only place for the solution. The user can say that "Well webstart says this is signed by a developer and that I specifically should not trust it, and the default is to cancel this operation - but I'll do it anyway, and then click ok a gain to confirm" and there is nothing that can be done to prevent that. However loading natives isn't 'free' in Java, nor applets, nor webstart. At the minimum you have to be signed just for the dialog to show up, then you still have to request the permissions of the container, then the user still has to accept them.
Further, on OSX this requires privelege elevation so even if the native library was hostile - its actions are fairly limited because the things that it wants to do (even as an admin) will require popping up a dialog to grant rights.
Incorrect - they can access any native library and in fact can access the exact same ones as an Active X control. They can make the exact same native calls. They can open windows, they can spawn off entire applications. There is nothing that they cannot do funcationality wise. You write an ActiveX program and send it to me in a PM and I will write a webstart that does the exact same thing - the exact same way you are doing it. Guaranteed.
System.loadLibrary() allows me to do anything you can.
You are aware that Java can talk to COM right?
Poor analogy - its more like knocking the guard unconcious and leaving him propped up so that people think he's still effective - making it easier to enter a machine at a more opportune time in the future (like when you're VPN'd into your corporate network). Rootkit is a nice and interesting tool and when I used to have to maintain a cluster of Linux boxes in the wild I was worried about it until someone pointed me to chkrootkit - which in every instance that I was able to check for, solved the problem. Same goes for getting past snort. A rootkit is fairly easy to find these days.
In the limited windows view of security yes. In the rest of the world (unix) there is a clear distinction between a root user, a user with administrative rights/group accesses, and regular users. How much do you to you know about unix, linux, solaris, aix, bsd, etc. security?
Phoenix said:
As soon as you introduce native code to the equation, as you point out quite correctly, the problem becomes trust, and not security.
And frankly, to be pedantic, webstart launches Java applications and a Java application is not a Java applet.
Phoenix said:
Ok. Write me an IE JVM plugin using only Java applets and without using ActiveX.
Sure.
But the whole point of this argument is that Java applets can't replace ActiveX.
You said:
Phoenix said:
"ActiveX controls" and "Java applets" do two different things and are not interchangable. Write me an IE JVM plugin using only Java applets and without using ActiveX.
Ok, back to this again.
1. If you're not an admin, you can't change the state of the Security Center. Sure you could wait and poll the Security Center to see if the virus or firewall is off for some reason, then do something. But if you're trapped in a regular user account, there's a lot less you can do even if the virus scanner or firewall is temporarily off.
2. If you are an admin, you don't need to change the state of the Security Center, because there is nothing anything in the system can do to stop you.
If you're an admin, you can bypass the virus scanner directly (load a lower filter driver into the disk stack that hides scan attempts coming from the antivirus filter driver).
You can bypass the firewall directly (load a lower filter driver that bypasses the firewall entirely).
And all of this without even the virus scanner or firewalls knowing themselves, let alone the security center.
I already addressed the way to detect a root kit.
If it's good you will need an offline scan of the hashes of all the binaries on the system, OR, if it's passing network traffic a packet sniffer will reveal it.
A smart rootkit will patch the kernel so the processes no longer show up and the files no longer show up. There's no way a local scanner can find it.
Ok what exact administrative rights are you talking about?
When I say admin I mean, explicitly: an admin is a user that has sufficient privilege to allow him to bypass any security restrictions placed on him. This can be as little as one privilege.
Example: If I have the right to load a piece of code into the kernel, I am an admin, regardless of any other permission mechanisms you set for me. For example, you may deny me access to a particular file, but I can just get around that by loading a driver which patches the kernel routine that does the security check. Therefore I am an admin.
Example: If I have the right to debug arbitrary processes, I am an admin, regardless of any other permission mechanisms you set for me. For example, you may deny me access to a particular file, but I can just get around that by opening up a privileged process in the system and altering its memory to execute any code I wish. Therefore I am an admin.
Example: If I have the right to write to a privileged system binary file, I am an admin, regardless of any other permission mechanisms you set for me. For example, you may deny me access to a particular file, but I can just get around that by altering the privileged system binary to execute any code I wish. Therefore I am an admin.
Example: You might be assigned the management of a group of users, but without other rights, you cannot do anything more than what Ive told the system to let you do. For example, if I deny you access to modify a particular user account, there is nothing you can do to alter that user account. Therefore, despite your ability to manage certain user accounts, you are not an admin.
Example: You might be assigned the ability to manage the file permissions on some part of the file system, but without other rights, you cannot do anything more than what Ive told the system to let you do. For example, if I deny you access to modify a particular file outside the set of files you manage, there is nothing you can do to alter that file. Therefore, despite your ability to manage the file permissions, you are not an admin.
Example: You might be assigned the ability to configure the screen resolution, but without other rights, you cannot do anything more than what I've told the system to let you do. For example, if I disallow you from resetting the colour of the desktop, there is nothing you can do to alter that restriction. Therefore, despite your ability to configure some aspect of the machine's hardware, you are not an admin.
Is that clear enough?
An admin is a user that has sufficient privilege to allow him to bypass any security restrictions placed on him. If you don't have this ability, you are not an admin.
Phoenix said:Next time you're in a round table at JavaOne in the JVM sessions - stand up and tell them why they use ActiveX because clearly they don't know themselves.
http://support.microsoft.com/default.aspx?scid=kb;en-us;303401
Even if it isn't the reason they stated at the round table, it's the reason now.
Phoenix: And just to head off you bringing up B2 and mandatory access controls, none of the big Linux-distros, nor OSX, nor Windows, nor just about any other PC OS I can think of supports that. Ok?
On any PC OS we're likely to use, a "true" admin can bypass any security on the system.
On any PC OS we're likely to use, a "true" admin can bypass any security on the system.
Phoenix
Member
aaaaa0 said:As soon as you introduce native code to the equation, as you point out quite correctly, the problem becomes trust, and not security.
And frankly, to be pedantic, webstart launches Java applications and a Java application is not a Java applet.
Nah, webstart can launch applets as well - just that noone ever uses it in that manner because applets are so passe now.
Ok. Write me an IE JVM plugin using only Java applets and without using ActiveX.
It would take too long and require more native code that I can write right now. It wouldn't be done in an applet but as a webstart executable. . I'll get you a rundown of how it'd be done however - and its the same approach that some malware uses.
Create the JVM plugin as a seperate process running in the systray and grab the process list. Listen to the system event delegation through the wndproc. Get the hWnd of the IE window. Get the browser windows URL, parse this for your plugin tag to see where it goes. Create a native OpenGL or Direct3D context there. Draw.
Its the same route that malware and spyware take and they aren't activex usually. The downside is losing cycles tracking the movement of the IE window and having to move the native drawing surface on the screen. The only difference here being that an ActiveX control will get notifications from the parent IE frame where my overlay window will have to systematically derive that information from the OS. Nevertheless they will look exactly the same because the first thing that one would do to implement similar functionality in an ActiveX control is call GetHWnd() to get the window handle which is necessary before making calls to drawing routines.
Been there - and have actually DONE that about 4 years ago during the great .com days. My reasons for doing it were so that users couldn't turn it off via the browser.... which, not surprisingly, is the reason why malware works external to the browser
And I don't disagree with this.
Again you assume a different type of attack that what I'm talking about.
Indeed, but its also something more likely to be detected. Again, we're talking about direct and indirect forms of attack. If I was admin I could format the drive, I could lock the screen, I could delete the security center, I could install a TSR, however these are all activities that a security researcher/center would find.
Checksum the binaries and compare them to an offline copy.
Okay here are a few from OSX: add user accounts, change energy saver preferences, run software update, lock drive, change the system clock/timezone/etc, install software that touches system directories.
Here are a few that you need root explicitly for:
MODIFY system directories/libraries, change any directory or file owned by root or the wheel group, run a process that requires running in the wheel group, run software on protected ports (less than 1024).
Here are a few that a regular user can use:
Change software, change the background or screensaver, run software that doesn't touch admin directories or that the admin gives them permission to run (admin granted sudo per app).
There is a very explicit difference.
In OSX this is not possible because it requires root. You can't hack around admin permissions to root outside of a bug in the kernel. During my port of JOGL to OSX one of the annoyances was that I would HAVE to run as root to do things of this nature because the OS is smart enough to know that I shouldn't be doing that as anyone other than root.
If that's your definition of admin - it differs from the Unix view of admins, root, and user access. Perhaps that's why Microsoft doesn't get it - they don't use enough Unix to know that their terminology is incorrect
Wow, I didn't even notice you'd posted back.
Wow, that is a hack.
First, you have to have the JRE installed before you can use or even install your plugin. (Ick.) Thats a big 15 MB download followed by a multi-step install wizard.
Then, you have to download a pile of native code, and have the user authorize and install that. (Double ick.)
Then, you have to be running as yet another horrible tray turd or at the very least another useless background process consuming working set and CPU cycles. (Bleech.) Tray turds are the worst things ever invented. Theyre the first thing I delete from anything I install. IM TALKING TO YOU ATI, NVIDIA, REAL, AND APPLE. ;-)
Then, you have to poke at IE through an unsupported and possibly fragile means to make yourself actually run. (Ultra ick.)
You get points for coming up with it, but I'd never ever ship a legitimate app using it.
Making a native code ActiveX and shipping a signed CAB would be 10x cleaner IMHO.
At least then I don't have to make the user install the JRE. ;-)
TSRs? Eh? Windows hasnt supported real TSRs since 9x.
If I was an attacker and I had admin, Id first install a boot load filter driver on the storage stack. The purpose of this filter driver (among other things) would be to intercept I/O requests coming down in order to hide the files that represented the rest of my rootkit. The next thing Id do is patch the kernel APIs for querying processes to skip the processes representing the rootkit (or I could patch the process list instead). Last thing Id do is patch the kernel debugger APIs to hide my driver from anyone trying to access kernel memory using a kd.
Any local scanner that tried to locate my files would not see anything. Anyone that checked for processes would not see anything. Just about the only way I can see you finding the root kit is if you shutdown the machine, booted from a clean OS, and scanned every file on the system vs known good hashes. Even then youd have to notice an extra couple files around that you didn't recognize.
Unless you do the whole thing offline (booted into a different clean OS), thats not enough, because I can fake your reads if I am running.
In Windows:
If youre in a domain environment, you dont need to be an admin to modify user accounts (you just need delegated management privileges on the OUs that you control). Local accounts are different, you must be a local Administrator to change those.
You do need admin to run Windows Update (for a lot of reasons, like you will need to reboot if you replace the kernel). You do NOT need admin for Automatic Updates (as of SP2).
You do not need need admin to change energy saver preferences.
You do need admin to change the system time (modifying the system time should be a privileged operation Kerberos wont authenticate you if you dont have an accurate system clock).
You do not need admin to install programs that use MSI installer packages and which do not modify system files.
On Windows:
You need to be a member of the Administrators group to change anything in the system directory because that group is by default granted permissions to the system directory. (BUT you do not necessarily need admin privs, just file system rights.)
You need admin to access any file you dont own or have permission to access (you can invoke the backup privilege to read the files and the restore privilege to write them).
You need admin to load a driver or install a service.
Windows doesnt enforce the notion of protected ports below 1024, though you cant hijack a port already opened by a system service today (at least not that I know of).
In Windows:
A regular user can change the background or screensaver in Windows unless the Admin has set one using group policy. Personal profile settings and per user app settings are in general not privileged -- they're stored in the ntuser.dat registry hive in the root directory of your profile.
A regular user can install software as long as it doesnt touch system directories or "Program Files". (Software that does not touch either is generally not common under Windows, but that's not microsoft's fault.) Even in this case it is possible to force apps to write to a private directory under the user's profile.
The tools to do this are here: http://msdn.microsoft.com/downloads/list/appcomp.asp?frame=true
Broken apps are not Microsoft's fault. The guidelines for writing apps have been there for years now.
A regular user can install software even if it touches system directories if its deployed securely via the domain policy or MSI.
Ok.
In Windows, the closest thing to the root user in Windows is SYSTEM which is what the OS itself authenticates as. No normal login prompt exposed by the OS will take SYSTEM as a valid user.
In Windows, Administrators are users that belong to the "BUILTIN\Administrators" group. This group by default has certain security privileges assigned.
The list of privileges is documented here (not all of them are granted to Administrators):
http://msdn.microsoft.com/library/e..._constants.asp?frame=true#privilege_constants
You can create any subset you want by constructing groups with subsets of the privileges assigned. Though generally speaking, many admin privileges tend to be logically equivalent so you have to be really careful about granting them. (For example, granting load drivers makes it trivially easy to get the others.)
The logical equivalent of the users group in Mac OSX, is the "Users" group in Windows.
The logical equivalent of the admin group in Mac OSX, in Windows, is the "Users" group, with some fancy UI magic to make temporary elevation of privilege easy for certain tasks.
The closest logical equivalent of "wheel" in OSX, I guess is the "Administrators" group in Windows. (I know wheel is unused in OSX, that's a very good decision.) And it's not really a good match, since "BUILTIN\Administrators" by default is assigned a bunch of privileges that are not assigned to "wheel". (Administrators are more powerful than wheel users, but less powerful than SYSTEM.)
The logical equivalent of "root" in OSX, is SYSTEM in Windows, except you can't actually log on as SYSTEM in Windows from any login prompt.
If setuid is granted for a particular app, doesnt that make that app a huge potential security hole? If a security bug in any setuid(root) binary exists, an admin can get root pretty easily. Thats not a kernel bug.
There is no setuid bit in Windows for this reason. But Windows does have SeAssignPrimaryTokenPrivilege (which is assigned to system services only by default).
Phoenix said:It would take too long and require more native code that I can write right now. It wouldn't be done in an applet but as a webstart executable. . I'll get you a rundown of how it'd be done however - and its the same approach that some malware uses.
Create the JVM plugin as a seperate process running in the systray and grab the process list. Listen to the system event delegation through the wndproc. Get the hWnd of the IE window. Get the browser windows URL, parse this for your plugin tag to see where it goes. Create a native OpenGL or Direct3D context there. Draw.
Its the same route that malware and spyware take and they aren't activex usually. The downside is losing cycles tracking the movement of the IE window and having to move the native drawing surface on the screen. The only difference here being that an ActiveX control will get notifications from the parent IE frame where my overlay window will have to systematically derive that information from the OS. Nevertheless they will look exactly the same because the first thing that one would do to implement similar functionality in an ActiveX control is call GetHWnd() to get the window handle which is necessary before making calls to drawing routines.
Been there - and have actually DONE that about 4 years ago during the great .com days. My reasons for doing it were so that users couldn't turn it off via the browser.... which, not surprisingly, is the reason why malware works external to the browser
Wow, that is a hack.
First, you have to have the JRE installed before you can use or even install your plugin. (Ick.) Thats a big 15 MB download followed by a multi-step install wizard.
Then, you have to download a pile of native code, and have the user authorize and install that. (Double ick.)
Then, you have to be running as yet another horrible tray turd or at the very least another useless background process consuming working set and CPU cycles. (Bleech.) Tray turds are the worst things ever invented. Theyre the first thing I delete from anything I install. IM TALKING TO YOU ATI, NVIDIA, REAL, AND APPLE. ;-)
Then, you have to poke at IE through an unsupported and possibly fragile means to make yourself actually run. (Ultra ick.)
You get points for coming up with it, but I'd never ever ship a legitimate app using it.
Making a native code ActiveX and shipping a signed CAB would be 10x cleaner IMHO.
At least then I don't have to make the user install the JRE. ;-)
TSRs? Eh? Windows hasnt supported real TSRs since 9x.
If I was an attacker and I had admin, Id first install a boot load filter driver on the storage stack. The purpose of this filter driver (among other things) would be to intercept I/O requests coming down in order to hide the files that represented the rest of my rootkit. The next thing Id do is patch the kernel APIs for querying processes to skip the processes representing the rootkit (or I could patch the process list instead). Last thing Id do is patch the kernel debugger APIs to hide my driver from anyone trying to access kernel memory using a kd.
Any local scanner that tried to locate my files would not see anything. Anyone that checked for processes would not see anything. Just about the only way I can see you finding the root kit is if you shutdown the machine, booted from a clean OS, and scanned every file on the system vs known good hashes. Even then youd have to notice an extra couple files around that you didn't recognize.
Unless you do the whole thing offline (booted into a different clean OS), thats not enough, because I can fake your reads if I am running.
In Windows:
If youre in a domain environment, you dont need to be an admin to modify user accounts (you just need delegated management privileges on the OUs that you control). Local accounts are different, you must be a local Administrator to change those.
You do need admin to run Windows Update (for a lot of reasons, like you will need to reboot if you replace the kernel). You do NOT need admin for Automatic Updates (as of SP2).
You do not need need admin to change energy saver preferences.
You do need admin to change the system time (modifying the system time should be a privileged operation Kerberos wont authenticate you if you dont have an accurate system clock).
You do not need admin to install programs that use MSI installer packages and which do not modify system files.
On Windows:
You need to be a member of the Administrators group to change anything in the system directory because that group is by default granted permissions to the system directory. (BUT you do not necessarily need admin privs, just file system rights.)
You need admin to access any file you dont own or have permission to access (you can invoke the backup privilege to read the files and the restore privilege to write them).
You need admin to load a driver or install a service.
Windows doesnt enforce the notion of protected ports below 1024, though you cant hijack a port already opened by a system service today (at least not that I know of).
In Windows:
A regular user can change the background or screensaver in Windows unless the Admin has set one using group policy. Personal profile settings and per user app settings are in general not privileged -- they're stored in the ntuser.dat registry hive in the root directory of your profile.
A regular user can install software as long as it doesnt touch system directories or "Program Files". (Software that does not touch either is generally not common under Windows, but that's not microsoft's fault.) Even in this case it is possible to force apps to write to a private directory under the user's profile.
The tools to do this are here: http://msdn.microsoft.com/downloads/list/appcomp.asp?frame=true
Broken apps are not Microsoft's fault. The guidelines for writing apps have been there for years now.
A regular user can install software even if it touches system directories if its deployed securely via the domain policy or MSI.
Ok.
In Windows, the closest thing to the root user in Windows is SYSTEM which is what the OS itself authenticates as. No normal login prompt exposed by the OS will take SYSTEM as a valid user.
In Windows, Administrators are users that belong to the "BUILTIN\Administrators" group. This group by default has certain security privileges assigned.
The list of privileges is documented here (not all of them are granted to Administrators):
http://msdn.microsoft.com/library/e..._constants.asp?frame=true#privilege_constants
You can create any subset you want by constructing groups with subsets of the privileges assigned. Though generally speaking, many admin privileges tend to be logically equivalent so you have to be really careful about granting them. (For example, granting load drivers makes it trivially easy to get the others.)
The logical equivalent of the users group in Mac OSX, is the "Users" group in Windows.
The logical equivalent of the admin group in Mac OSX, in Windows, is the "Users" group, with some fancy UI magic to make temporary elevation of privilege easy for certain tasks.
The closest logical equivalent of "wheel" in OSX, I guess is the "Administrators" group in Windows. (I know wheel is unused in OSX, that's a very good decision.) And it's not really a good match, since "BUILTIN\Administrators" by default is assigned a bunch of privileges that are not assigned to "wheel". (Administrators are more powerful than wheel users, but less powerful than SYSTEM.)
The logical equivalent of "root" in OSX, is SYSTEM in Windows, except you can't actually log on as SYSTEM in Windows from any login prompt.
If setuid is granted for a particular app, doesnt that make that app a huge potential security hole? If a security bug in any setuid(root) binary exists, an admin can get root pretty easily. Thats not a kernel bug.
There is no setuid bit in Windows for this reason. But Windows does have SeAssignPrimaryTokenPrivilege (which is assigned to system services only by default).
Phoenix said:If that's your definition of admin - it differs from the Unix view of admins, root, and user access. Perhaps that's why Microsoft doesn't get it - they don't use enough Unix to know that their terminology is incorrect
We just have different definitions of admin.
What you call admin, I call "regular user with Run As...".
You're just arguing semantics here. What we're saying is not significantly different.
- Status
Similar threads
- Locked