At 02:36 PM 10/10/99 +1000, Mark Dixon wrote: >> > > > >4) Put a binary on the system [snip] >> > UNC paths may not work in this instance. Not all paths contained in >the >> > registry can be remote. I'd have to test this to be sure, >I already tested this before I posted. I should have said UNC paths do >work here. OK - I hadn't checked this one explicitly, and it is nice to know the exact parameters of your risk. >I have a machine which Dr.Watsons reliably when running SRVINFO.EXE >against a particular host (I haven't figured out why yet...) Maybe a samba box? Samba will often give things back to Win32 API calls that NT won't and it can violate the programmer's assumptions. The Net*() family of APIs all write back a valid pointer to the struct you asked for if they return success. Samba, OTOH, will sometimes give you back a success, but decide not to give you any information, so the pointer you thought was valid is really null, and boom. >Sure enough when I fired up SRVINFO it crashed and ran the >executable from the remote share. I was careful to make sure the share >was being accessed using guest privileges (verified in the security >log). Nice to know that - thanks for testing. >> > that it may be dependent on what user caused the debugger to fire. > I'm not quite sure what you mean here... true I crashed the process >as administrator on the machine SRVINFO was running on, but I can't see >why this should make any difference if I was using an unpriveliged >account or an Administrator. It regulates whether the 'debugger' is going to run as an ordinary user or some higher level user. Means that I can't log on at a student kiosk, crash my own app and take over the machine. > If you're refering to whether it would work without a user logged in >(say a service crash at the logon screen) then you may well be right. I >haven't tested this. Does the debugger fire when no one is logged in ? I >imagine it does but I've never seen a Dr Watson at the login screen. I'd suspect you'd be getting it to run as localsystem at that point. > At any rate an Administrator logged in at the console is definately >would be vulnerable to someone using this type of attack to elevate >privileges. It's just one more reason to not use administrator accounts >unless you really have to. Absolutely. There are several other keys in this area where someone might be able to stir up trouble - see Steve Sutton's NSA paper at http://www.trustedsystems.com/NSAGuide.htm for additional details. What I recommend here is: 1) Go set the ACLs on keys in this area to something a bit stronger. If you're using the Security Configuration Editor, make a template that tweaks out all of them the way you want them and run around applying it to all your servers (BTW, you have to be admin to get to this area on a workstation remotely). 2) I strongly suspect that everyone does not need HKLM\Software\Microsoft\Windows NT\CurrentVersion in the AllowedPaths value located at HKLM\System\CurrentControlSet\Control\SecurePipeServers\Winreg. The thing to do would be to set auditing for the network user on the CurrentVersion tree, and see if any non-admins really access it. If they don't, then it is probably safe to remove it from the AllowedPaths value. I would be really interested in hearing from anyone who has tried this and what their results are. David LeBlanc dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:07:25 PDT