Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Operating Systems Programming Software Windows Technology

Coding Around UAC's Security Limitations 334

Mariam writes "Free software developers from the non-profit NeoSmart Technologies have published a report detailing their experience with coding around Windows Vista's UAC limitations, including the steps they took to make their software perform system actions without requiring admin approval or UAC elevation. Their conclusion? That Windows Vista's improved security model is nothing more than a series of obstacles that in reality only make it more difficult for honest ISVs to publish working code and not actually providing any true protection from malware authors. Quoting from the post: 'Perhaps most importantly though, is the fact that Windows Vista's newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security. Any program that UAC blocks from starting up "for good security reasons" can be coded to work around these limitations with (relative) ease. The "architectural redesign" of Vista's security framework isn't so much a rebuilt system as much as it is a makeover, intended to give the false impression of a more secure OS.'"
This discussion has been archived. No new comments can be posted.

Coding Around UAC's Security Limitations

Comments Filter:
  • by fahrbot-bot ( 874524 ) on Sunday April 27, 2008 @05:05PM (#23217036)
    ...Windows Vista's newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security...

    Sounds like it was written by Homeland Security and the TSA.

    • by dhavleak ( 912889 ) on Sunday April 27, 2008 @05:30PM (#23217234)

      Sounds like it was written by Homeland Security and the TSA.
      That's BS and so is TFA. The part you quoted (which was in bold in TFA) is just an anti-UAC rant thrown in to get attention, and clearly it worked.

      The so-called work-around described in TFA:

      • - Split iReboot in two parts, a background service and a userspace client
      • - Background service runs as SYSTEM or LOCAL SERVICE
      • - Userspace client runs unprivileged
      • - Installing iReboot now requires an installer
      • - The installer requires admin privileges (i.e. you will see a UAC prompt when installing)

      Gee, sounds to me like UAC is working exactly the way it should!

      • Gee, sounds to me like UAC is working exactly the way it should!

        Something from MS working like it should... sounds strange, isn't it? And what's more - Slashdot agrees that it works!
      • Re: (Score:2, Insightful)

        by Sique ( 173459 )
        Yes, a ticket pointing out the error would be send back with "works as designed".
        But the design is flawed. The idea was that user interaction shouldn't be able to autostart a program which is able to modify system functions. But it is sufficient to have an autostart program remote control another autostart program to get exactly this behaviour.
        • by dhavleak ( 912889 ) on Sunday April 27, 2008 @06:15PM (#23217552)

          But the design is flawed. The idea was that user interaction shouldn't be able to autostart a program which is able to modify system functions.
          That's not accurate. I don't know what gives you the idea that this was MS's intention. From everything I've read, UAC is not intended to block this scenario -- just to force the architecture to be split in this way, compelling the developer to use an installer that will prompt for elevation when installing the service.
        • by wwahammy ( 765566 ) on Sunday April 27, 2008 @06:23PM (#23217602)
          No it is working as designed. To install software that will modify the system, you need to use elevated privileges. Once you have elevated privileges you can do anything you want, including installing services that autostart. This is no different than installing an additional daemon on Unix-y systems. If you feel that is a security vulnerability, how do you intend to get anything done? Just a list of some of the different services that autorun on my computer:
          -The base filtering engine used by the Windows Firewall
          -Computer Browser keeps track of other computers on the network
          -Plug and Play
          -Print spooler
          -Event log
          -Task scheduler
          -Firewall

          If these things didn't autorun, I'd have a pretty different system. That or everything would run as an administrator and we'd be right back to Windows XP with the same problems we had before.
          • Re: (Score:3, Insightful)

            by darkpixel2k ( 623900 )
            and we'd be right back to Windows XP with the same problems we had before.

            What problems? I run a network of about 80 XP machines. They all run fairly well--aside from the occasional failed Windows Update. Recently someone introduced a Vista laptop to the network. It can't print because the print spooler constantly crashes (with all 5 of the variety of printers on the network), if you plug it in to the network at one site it flat out refuses to talk to anything--even after trying for 45 minutes to get
            • I was referring mainly to the idea of every user running as an administrator which was used by most home users. Regarding your script, UAC can be disabled for administrators (or anyone) via secpol.msc. From then on, the administrator mode will run as one would expect. Whether you can change that though is dependent on your organization's security policies.
          • Re: (Score:3, Insightful)

            Yeah, I have to agree that this sounds like Vista is actually doing its job. You can argue that malware can take advantage of this system, but such malware would require social engineering to get itself installed, rather than doing it on the sly.

            The author of the article basically lauds XP's "everybody runs as an administrator" scenario as if it was a good thing, then goes on to complain that Microsoft forcing him to play by their rules rather than by his own is somehow a bad thing.

            In other words, system h
        • by tepples ( 727027 )

          But it is sufficient to have an autostart program remote control another autostart program to get exactly this behaviour.
          The problem of The Article was that Win32's interprocess communication is designed in such a way that the remote control takes an order of magnitude more code than the business logic.
          • by ericlondaits ( 32714 ) on Sunday April 27, 2008 @11:50PM (#23219694) Homepage
            I've written lots of applications that use COM for IPC and it's incredibly easy to do... just define an object and it's methods on one side... instantiate and call in the other. If you use the right COM bindings (MFC, ATL, Visual Basic, JScript, etc) the code it's quite clean, short and to the point. ... granted, COM has a very steep learning curve, just like RPC, Corba, etc... but I guess that although it wasn't the path I took, you can use just a small portion of COM (over ATL or VB) for IPC without worrying about the underlaying structure, apartment models, class factories, reference count, etc.

            Other than that, the IPC primitives Win32 provides (message queues, pipes, etc.) are about the same complexity than UNIX's and really shouldn't take that much code.
          • Re: (Score:3, Interesting)

            by Allador ( 537449 )
            Well sure. Thats almost always the case, regardless of platform.

            Doing something sloppy and wrong is often easier and less time consuming than doing things right.

            This article is just that case.

            NeoSmart was getting a free ride by being bad developers, and assuming that everyone was running as admin, and that someone would always be logged into the box.

            Now they're being forced to learn how to program correctly, and do things right, and yep, it takes more lines of code.

            Doing things the right way almost always
      • Re: (Score:3, Insightful)

        by Tony Hoyle ( 11698 )
        Except nearly all installers use admin privileges, because the Program Files directory (to name just one) isn't per-user. Windows really isn't structurally designed for per-user installation, although MS have tried it's still half finished. Users know this, and always click yes on installers when prompted.

        Any installer can stick a service in there that does privileged tasks, and that means UAC is a thin layer that's easy to work around.
        • Re: (Score:3, Insightful)

          by drsmithy ( 35869 )

          Except nearly all installers use admin privileges, because the Program Files directory (to name just one) isn't per-user. Windows really isn't structurally designed for per-user installation, although MS have tried it's still half finished. Users know this, and always click yes on installers when prompted.

          So it's just like /bin, /usr/bin and /Applications, then ?

          Any installer can stick a service in there that does privileged tasks, and that means UAC is a thin layer that's easy to work around.

          How is th

          • Re: (Score:3, Interesting)

            by peragrin ( 659227 )
            well /Applications is for everyone. your supposed to install it there. Any where else and your app is misbehaving anyways.

            In fact 99% of applications shouldn't need an installer for OS X. Just a drag to the /Applications folder. Installers are messy, if you need one your app is already designed wrong.

            MSFT has turned a single user OS and tacked on multi user support, and then multi user security. OS X, and every *nix are Multi-user OS's. I not only have applications but also user specific applications
            • You could install all of those on a per-user basis, provided the installer was set up to do so. As long as any registry entries modified are for the current user and the application files are kept in a location available to the current user, your application would probably work fine. It's certainly not as easy as dragging to /Applications but there's nothing stopping a developer from doing so.
            • by drsmithy ( 35869 ) <drsmithy@gmail. c o m> on Sunday April 27, 2008 @06:30PM (#23217674)

              well /Applications is for everyone. your supposed to install it there. Any where else and your app is misbehaving anyways.

              Exactly. Just like %PROGRAMFILES%.

              MSFT has turned a single user OS and tacked on multi user support, and then multi user security. OS X, and every *nix are Multi-user OS's.

              False. Windows NT is, and always has been, a multiuser OS.

              I not only have applications but also user specific applications stuff that only I can run, and stuff that only I can see.

              And you can do exactly the same in Windows.

              You shouldn't have to be an admin to install a web browser, word processor , or spreadsheet. You should only be an admin if your installing it for everyone.

              So, just like Windows then ?

              • by IchBinEinPenguin ( 589252 ) on Sunday April 27, 2008 @07:10PM (#23217802)
                > MSFT has turned a single user OS and tacked on multi user support, and then multi user security. OS X, and every *nix are Multi-user OS's.

                False. Windows NT is, and always has been, a multiuser OS.


                I've long thought that the single vs multi-user nature of Windows NT and Unix has more to do with user expectations than technical limitations.
                Unix users were brought up on multi-user envoronments. root had to do stuff like install system-wide apps, printers etc.
                Users never expected to be able to do this, and aplications developers coded knowing these limitations.

                Windows users, on the other hand, evolved out of DOS users (please note that I'm talking about users not the underlying codebase). DOS users have always had unrestricted access to their system, and this expectation was inherited by modern-day Windows users.
                Equally importantly, application programmers did not code with these limitations in mind.

                What you end up with is a platform that's technically perfectly capable of being multi-user, but hamstrung by user expecteations and badly designed applicaitions.
              • by Dolda2000 ( 759023 ) <fredrik&dolda2000,com> on Sunday April 27, 2008 @09:59PM (#23218936) Homepage

                False. Windows NT is, and always has been, a multiuser OS.
                Indeed -- the NT kernel is, and always has been, a multiuser kernel. That does not, however, make Windows a multiuser operating system, if I may say so. I, too, would think that the GP doesn't really know what he's talking about, but when put into another perspective, his argument that "multiuser support has been tacked onto Windows" isn't unfair in any way.

                If Microsoft had indeed taken the NT kernel and built a sensible operating system above it, it would have been a multiuser system, but they didn't. Instead, they took the entire DOS and Windows 3.x world and put the NT kernel underneath it. Technically speaking, they rather tacked a single-user mindset and framework on top a multiuser kernel, making a single-user operating system. Since the NT kernel basically was written to supplant Windows anyway, it isn't entirely biased to argue that multiuser support was tacked onto Windows.

                Of course, I am still not arguing against the NT kernel. Microsoft could just as well have done the same thing with the Linux kernel as well, and the result would have sucked as badly. In fact, I don't know very much about the NT kernel internals (since the documentation isn't quite as easy to get at as it is in Unix), but I would guess that it isn't an entirely bad idea at an operating system kernel. Unfortunately, the kernel alone doesn't make an operating system, and Microsoft decided to build a basically single-user system on top of the kernel.

          • by jedidiah ( 1196 ) on Sunday April 27, 2008 @09:56PM (#23218910) Homepage
            ...except a proper Unix can install into /home/user.

            A number of applications do this by default and will complain or
            just plain bail out if you try to install them as root.

            Also, something like /Applications can be set up so that multiple
            users can create new directories in it but not necessarily stomp
            on each other.

            On other platforms, services tend to not be installed as superuser.

            The fact that none of this occurs to you just shows how ingrained
            the whole "run everything root" idea is in Windows user culture.
      • by BLKMGK ( 34057 )
        Article is down so not able to read it but I believe you are correct. Any request to elevate privs is supposed to pop a UAC. A program sans manifest will also pop it - Vista apparently assumes if there's no manifest then the program wasn't written for Vista. Add a manifest and no UAC unless elevated privs are requested, just set it to use existing privs. Installing a service is going to need privs ergo a UAC. UAC working as designed it seems. How is this HomeLand exactly? Find a backdoor in BitLocker, then
    • Re: (Score:3, Insightful)

      by Anonymous Coward
      Slashdot loses a little relevance and credibility every time a stupid post like this one is green lighted. Submitter should read before submitting.
  • A Service... (Score:5, Informative)

    by maz2331 ( 1104901 ) on Sunday April 27, 2008 @05:10PM (#23217070)
    Basically, all they had to do is split the thing into a front-end "userspace client" and a back-end "service".

    Gee, sounds like a daemon that can be controlled from an application to me.
    • Re:A Service... (Score:5, Informative)

      by Gazzonyx ( 982402 ) <scott.lovenberg@gmai[ ]om ['l.c' in gap]> on Sunday April 27, 2008 @05:40PM (#23217318)
      Yeah, but I think the win32 API's message pump is probably the Achilles heal... I've heard that it's been redesigned so that you can't pierce it by getting kernel space threads to execute your program with a callback in the messaging interfaces, but any time that you have a secure system, that front end and the back end should be fairly tight together. If they could intercept the messaging between front end and back end, I'd hazard a guess that the interfaces weren't snug enough. Then again, given 'physical' (if we will allow software to be considered physical for a moment) access to *any* machine, it's no longer yours. That's probably why *nix'es are very, very specific about separation of concerns and granting the least possible permissions to a limited service account.

      Unfortunately, tying the desktop environment, window manager, and kernel together into a tightly integrated package will increase the damage per amount of attack vector surface area, should a single link in the armor be broken. In Windows, you've only got about 3 accounts, Local System, Network Service, and Everyone group. If a single service gets owned, it's running rogue at the same level of permissions, system wide, as root. Regardless if it's a crappy HP driver service, a hypervisor, or explorer. All that to say, the design is flawed such that not only are these things possible, but they have greater consequences than they would under other OSes.
      • by Jaime2 ( 824950 )
        The message pump is simply carries two arbitrary 32-bit payloads. If one of those happens to be a callback, so be it. The message pump is not is charge of stopping the kernel component from calling the code that the callback references, the Windows memory model does that. Since Windows 95 and since the conception of Windows NT, the kernel component would have to specifically map memory from the application's address space to call it, this couldn't be used as a code injection vector.

        That's probably why *nix'es are very, very specific about separation of concerns and granting the least possible permissions to a limited service account.

        How exactly are *nix

        • That's only if it runs as LocalSystem or Administrator. If someone is stupid enough to run services as those accounts, then they get what they deserve. How would that be any different from running a daemon as root in Linux?

          OK, a lot of this reply is over my head about Windows internals, but popping open my services list on a fairly vanilla XPx64 install, damn near everything runs as localsystem, except for a few network-related services.

          • by Jaime2 ( 824950 )
            Services that perform a simple task might be safe to run as LocalSystem. IIS is a good example. The core IIS functionality like listening on the network, reading HTTP headers, routing requests to the correct sub-process, run as LocalSystem. Anything content related like reading a file or running a server side script are launched in a seperate process from IIS as a specific user.

            If you see someone running a database server or an email server as LocalSystem, then they should be "talked to", this is bad p
          • Re:A Service... (Score:5, Interesting)

            by TheRealSlimShady ( 253441 ) on Sunday April 27, 2008 @09:56PM (#23218912)
            What you find in Vista (not XP unfortunately) is that a lot of the services that run with LocalSystem now run as "restricted" localsystem. They've profiled each service and figured out exactly what access it needs to run, and then granted that service those rights and no others. So while it looks like LocalSystem/Network Service it actually has reduced rights. Which is a good thing.
        • The message pump is simply carries two arbitrary 32-bit payloads. If one of those happens to be a callback, so be it. The message pump is not is charge of stopping the kernel component from calling the code that the callback references, the Windows memory model does that. Since Windows 95 and since the conception of Windows NT, the kernel component would have to specifically map memory from the application's address space to call it, this couldn't be used as a code injection vector.

          I was referring to a Shatter attack [wikipedia.org]. Although I don't know the least bit about it to speak with any kind of authority whatsoever, so it may be a non-issue.

          That's probably why *nix'es are very, very specific about separation of concerns and granting the least possible permissions to a limited service account.

          How exactly are *nix'es very, very specific about least priveliges? Admins are taught this, major packages in big distributions follow this rule. But, *nix'es don't enforce it, they only suggest it in the documentation. Any user that runs a personal *nix desktop that they installed themselves is not going to do it right. UAC was Microsoft's attempt to enforce good behaviors for people who don't know any better. Of course it was only partially successful because it is impossible to force people not to compromise their own systems.

          I meant that the file system hierarchy is split up in such a way that it makes running services with limited credentials easier (i.e. chroot), the UIDs and GIDs are specifically marked such that the first 100 are reserved for services (although, as you pointed out, that doesn't mean that people will follow this convention, but it is explicit, nonethel

    • Re: (Score:3, Insightful)

      by Dogun ( 7502 )
      Which is fine, provided the interfaces exposed by the daemon aren't themselves insecure.
      • Exactly. Since the service can be accessed by unauthenticated user-mode code the program is now a DOS vulnerability. Any program can screw with with the system by interacting with the service.

        They haven't proved anything. The UAC interaction was at the point of installaiton in this case. Once the user agrees to that, they are 0wned.
  • Film at 11 (Score:5, Funny)

    by symbolset ( 646467 ) on Sunday April 27, 2008 @05:10PM (#23217072) Journal

    Some clever programmers found a way to force a Vista PC to obey a user with admin rights.

    I'm sure there will be a patch to fix this glaring security hole in the next batch of updates.

  • Much as I like seeing Microsoft humbled, the comments on the original article seem to exonerate Microsoft of being as stupid as the article makes them sound. Lazy, perhaps, but not that stupid.
    • Re: (Score:2, Insightful)

      by cheater512 ( 783349 )
      Having a bigger marketing department than a programming department for a software company sounds pretty stupid to me. ;)
      • Re: (Score:3, Insightful)

        Does having bigger $$$ than anyone else around precisely because of that also sound stupid?
      • by swillden ( 191260 ) <shawn-ds@willden.org> on Monday April 28, 2008 @12:57AM (#23220124) Journal

        Having a bigger marketing department than a programming department for a software company sounds pretty stupid to me. ;)

        Really? I've worked for over a dozen software companies in my career and the only two that didn't have more people in sales and marketing than in engineering and product development are also the only two that are out of business.

        There are exceptions, I'm sure, but I think it's pretty normal that it takes more salespeople to sell a product than it takes engineers to design it.

    • by sjames ( 1099 )

      The article does make a mountain out of a molehill. While not the most eligant, UAC worked as intended and for that matter in a valid way.

      It's too bad that MS doesn't support the suid bit or capabilities and something like setuid (or seteuid). For one, it would make things like this simplicity itself.

      More importantly, it would allow an admin to properly support users without knowing their passwords and allow simple programs to handle any odd corner cases.

      After all these years, it would still seem that

  • by Anonymous Coward on Sunday April 27, 2008 @05:11PM (#23217082)
    The article uses a play out of Microsoft's playbook for Vista compatibility -- break an application that requires admin privileges into two parts: a privileged service and an unprivileged UI. Nothing to see here, move along.
    • by tepples ( 727027 )

      The article uses a play out of Microsoft's playbook for Vista compatibility -- break an application that requires admin privileges into two parts: a privileged service and an unprivileged UI.
      With interprocess communication (IPC) between the two.

      Nothing to see here, move along.
      The article said it took an order of magnitude more code to do the IPC than to do the business logic. I guess this means Win32's IPC is more byzantine than that of *n?x.
      • by Dogun ( 7502 )
        Most of the time people were not testing as std. user in the first place, and that's why they have issues in Vista.

        As far as IPC? Use RPC. It's really not that hard.
  • by Anonymous Coward on Sunday April 27, 2008 @05:12PM (#23217086)
    The "bottom line" starts off saying it wasn't easy, took much additional code, and many man hours of work. Then the next paragraph tells you it's "easy to code around".

    This is the problem with Blogs. It looks like journalism, but it isn't.
    • Re: (Score:3, Insightful)

      by Sique ( 173459 )

      This is the problem with Blogs. It looks like journalism, but it isn't.
      You saying, a journalist would provide a counter point from Microsoft? Because glaring logical gaps are nothing new for journalism.
      • This is the problem with Blogs. It looks like journalism, but it isn't.
        You saying, a journalist would provide a counter point from Microsoft? Because glaring logical gaps are nothing new for journalism.
        One could say instead:

        "This is the problem with television news. It looks like journalism, but it isn't", which I think is your point.

        It still doesn't make blogs any better, though.
  • If and when Microsoft closes those loopholes, any software that abuses them will break.

    On the plus side, it's another reason for customers to buy the next version of your software...

    Hmmmm, would a ISV make more money overall by deliberatly NOT being forwards compatible? are some intentionally breaking the bounds of the published SDK for this reason?
    • Re: (Score:3, Insightful)

      by Allador ( 537449 )

      If and when Microsoft closes those loopholes, any software that abuses them will break.
      They're not loopholes. They're one of the well known ways of solving the problem the neosmart devs created for themselves.

      The NeoSmart folks just were being lazy and assuming everyone was an admin, and that someone was always logged into the OS.
  • UAC is shite (Score:2, Insightful)

    by syousef ( 465911 )
    I care about security. A lot. I do my banking on my home PC and any kind of fraud or identity theft has the potential to make my life hell. Still, not only do I not run Vista (except on a laptop which it came pre-installed on and which I dual boot with XP as default) but the first thing I do is turn UAC off. It's not just painful, it's no more secure than putting 100 locks on your front door. Burgulars and home invaders can still kick the fucking thing down, only now it takes you an hour to get into your ow
  • by w3woody ( 44457 ) on Sunday April 27, 2008 @05:17PM (#23217132) Homepage
    So he created a service that runs with the necessary privileges to do what it needs, which communicates with a non-privileged front-end, and which requires privileges to install.

    How is this a "hack"?

    Perhaps the author of iReboot didn't see the rational for isolating a piece of code that needs to do something privileged and having it install and run in a user account which has sufficient permissions to allow it to run--but from a security standpoint this is no different than in Linux, where privileged code runs in a separate account from the user, and where IPC is used to communicate with that process.
    • by vux984 ( 928602 ) on Sunday April 27, 2008 @05:36PM (#23217276)
      I agree. This is so utterly not a hack that the article comes off as almost ridiculous.
      In fact the first response where it was announced is:

      Uhh... I'm running an admin application on startup automatically all the time, there's no need to create a service or anything. Just use the Task Scheduler to start the application, Trigger=At log on; And select "Run with highest privileges".

      MS had NEVER set out to prevent elevated applications from running at startup.
    • by Z34107 ( 925136 )

      So he created a service that runs with the necessary privileges to do what it needs, which communicates with a non-privileged front-end, and which requires privileges to install.

      Indeed! That's exactly how it's supposed to work.

      It's also what Steam did when they ported their client to Vista - the privileged parts (presumably code that decrypts game files or mucks about with your .gcf's in the program files directory) are installed as "Steam Client Service." After an admin installs it (with UAC prompt

    • This is how MS recommends you do it! Suppose you have something like a virus scanner. You need to have admin access to perform some of your tasks. Also, you should be running at all times in the background, not just when a user is logged in. Well this mean you don't want to just run as a program that ask for admin. This is problematic because it'll get annoying to the user (since it'll ask on every login) and since that if no user is logged in, virus protection is inactive.

      The right answer, and the answer t
  • One of our recent projects involved hosting a .NET control in Internet Explorer as part of an Intranet page for editing and uploading photos. The control worked fine, and we were able to manage security permissions such that it could access the files it needed to (and even delete them after as desired - it has full trust).

    The problem was that we wanted the page to refresh after the upload was complete. This seems like it should be fairly simple, but with how the security works, there's not a simple way to
    • perhaps this is why we're seeing so many sites putting all their 'useful' interactivity in flash. (or silverlight). MS's "security" has broken everything so much even they have started to work around it.
      • I think we see so many sites put their 'useful' interactivity in flash for the same reason as the Browser Wars days... It still takes effort to maintain cross-browser compatibility and look-and-feel in a Web 2.0 application.

        Flash code is maintained compatible by all the browsers running the same flash engine, which Adobe has a vested interest in keeping compatible across architectures. Sounds like a good opportunity for me to write a piece of code once and only once, which I'd jump at.
    • by TheRealMindChild ( 743925 ) on Sunday April 27, 2008 @05:45PM (#23217350) Homepage Journal
      Dude. You just create an event in your control, and implement a scripted handler on the page. Not exactly rocket science.
  • More fud (Score:5, Insightful)

    by ryan_hurst ( 1280216 ) on Sunday April 27, 2008 @05:22PM (#23217172)
    So they created a service (daemon) that exposed a interface that had no ACL on it that allowed the caller to perform privliged opperations, they had the administrator (root) install the service and grant it administrative permissions (again, root) and then had a unprivliged application call that interface. Sounds exactly like unix to me, more over short of not having ACLs on the interface, Microsoft has white papers telling folks how to do just this. In fact a CS major would know this as "least-privliged-design" oh-no mr. bill. Only on Slashdot would this qualify as news.
  • Misleading Summary (Score:5, Interesting)

    by Manip ( 656104 ) on Sunday April 27, 2008 @05:22PM (#23217174)
    I'm sorry but their "bypass" was to create a service running in an elevated state and then communicate with said service via exposed APIs.

    I fail to see how they drew this conclusion:
    "[UAC does] not actually providing any true protection from malware authors"

    This isn't a hole in the system. If applications couldn't use services running at admin or system then the entire system would be damn near nonfunctional.

    I mean how would you even play music without a regular application being able to communicate up safely to the driver?

    The article is fine. The person who wrote the summary didn't actually RTFA and is just trolling. They haven't justified anything they've said.
     
    • by Compuser ( 14899 )
      I think the assumption of iReboot folks was that UAC would insist on asking you anytime the installed software did anything requiring privilege elevation. I think this is a testament to how intrusive the UAC currently is that people assume this as the intended behavior.

      Side note: if you do assume that any privileged transaction should require a user prompt then surely allowing services to do admin stuff without prompting the user every time is a flaw.
  • It sounds to me like the separate process model that they are complaining about Microsoft forcing on them is... better.

    It's a lot easier to make an isolated service with rigidly defined IPC secure than it is to make something that interacts directly with the user secure.

    But maybe it's all that unix poisoning my brain.

    • No. They have could start their little program using the windows scheduler instead writing this mess of service-frontend stuff. From one of the comments:

      The problem simply is that the old registry keys for autostart have no way of specifying whether the started program should be elevated. Automatically (silently) elevating all autostart programs is a bad idea (non-elevated code can add autostart programs), and showing an elevation prompt pop up after every login is also a bad idea (I need to confirm a UAC prompt to login?). So Microsoft ended up with that "autostart program was blocked" solution. It's not a good idea, but it's less bad than the alternatives. But there was no intention of blocking programs from starting silently elevated, provided they are registered for autostart somewhere were only admins have access and where elevation can be explicitly controlled (because silently elevating just because some program says so is a bad idea). This is not possible with the Run registry key, but it's possible with the task scheduler.
      Sure, the task scheduler is a service, but the tasks it starts run in the user's session, so they can display UI. There's no need to write a custom service and use inter-process communication between a non-elevated UI and a service.

      This is not Vistas fault. It's just that the programmer did not know how to do it the windows way and ended up writing something insanely complicated to do the job, when something really simple would have been sufficient. Now he knows how to do it right, and in the next version he can use the scheduler to start his program, and trash all the service-fronte

    • It's a lot easier to make an isolated service with rigidly defined IPC secure than it is to make something that interacts directly with the user secure.

      But it's also a pain in the behind when your platform's IPC APIs are so byzantine that the code for the IPC is an order of magnitude bigger than the code for the business logic. I can't provide a direct quote from the article as I type this because "The connection to the server was reset while the page was loading", but I do remember it going from 100 lines to 1200.

  • by Mark Programmer ( 228585 ) on Sunday April 27, 2008 @05:39PM (#23217302) Homepage
    With respect to the iReboot team (who seem to have written a pretty nifty piece of software and certainly know their way around programming), there is so much spin on this article that light passing near it bends.

    The "Gory details" portion of the article gives a pretty good explanation of the work they had to do to make iReboot access high-permission OS features via a low-permission client. I have no idea how they got from there to "Any program that UAC blocks from starting up 'for good security reasons' can be coded to work around these limitations with (relative) ease." What they seem to be missing is that there was an installer in the loop---an installer that requires admin privileges. This is exactly the part of the process that UAC is trying to force upon Windows developers!

    The most significant problems with the Windows XP security model are as much social as technical. Because the model didn't make it easy to get "serious work" done as a non-administrator, most people are running as administrators most of the time. This creates a whole culture that is very vulnerable to social engineering---simple games are being run at the same permission level as complex drive-recovery utilities and keyboard loggers.

    By having people run low-privilege by default and escalating when necessary, the UAC model forces developers to be a little clearer about what their applications are doing (since things that "just worked" in WinXP now require permission in Vista). My understanding is that the way iReboot works now is the way it should always have worked, under the Windows OS model; the fact that it also worked if the user were running as an administrator was a happy accident. How well did the old iReboot work if I wasn't running as an administrator? If the answer is "It didn't," then, well, maybe they were doing it wrong the whole time.

    UAC has some problems, but the fact that it puts more work on developers isn't one of them. The work is necessary because it is accounting for a weaker security model from the past. And developers should know that security isn't free.
    • by drsmithy ( 35869 )

      The most significant problems with the Windows XP security model are as much social as technical. Because the model didn't make it easy to get "serious work" done as a non-administrator, most people are running as administrators most of the time. This creates a whole culture that is very vulnerable to social engineering---simple games are being run at the same permission level as complex drive-recovery utilities and keyboard loggers.

      There is _nothing_ in Windows's "security model" that requires - or even

      • by Hucko ( 998827 )
        You're the first that I can think of to suggest (and you did say it out right) that MS Windows might actually have a better security model than Unix. Can you direct me to follow up your train of thought?
        • by Tacvek ( 948259 ) on Sunday April 27, 2008 @07:40PM (#23217986) Journal

          You're the first that I can think of to suggest (and you did say it out right) that MS Windows might actually have a better security model than Unix. Can you direct me to follow up your train of thought?
          Well, my guess is that Windows NT being surprisingly Unix like at the lowest level may have something to do with this. The everything is a file model of Unix exists in NT, although the Win32 API hides this. However, one notable difference is that the kernel's internal file system has had full ACL support for just about everything for far longer than most UNIX's have. Most Unices are still stuck with the file has 1 owner, 1 owning group, and a total of 9 security bits. also consider that the NT system makes no assumption about some form of superuser account existing. Any account can be granted any of the "superuser" style rights it needs independently of any other. (Obviously, some such rights, such as direct read/write access to kernel memory may open up privilege escalation vectors, but that is a bit of a given.) Those sorts of things.
      • Re: (Score:3, Informative)

        You're absolutely right, and I misused the term "model."

        When I said "model," I was referring to the aggregate of the actual model and the way the model is exposed for the average consumer (who in WindowsXP, is usually running as an administrator for even the simplest tasks, either due to poorly-written software or their account simply having been configured by default as an administrator). There is just too much software in Windows XP that wants administrator privileges for questionable reasons---so much th
      • by IchBinEinPenguin ( 589252 ) on Sunday April 27, 2008 @07:25PM (#23217884)
        >This creates a whole culture that is very vulnerable to social engineering---simple games are being run at the same permission level as complex drive-recovery utilities and keyboard loggers.

        There is _nothing_ in Windows's "security model" that requires - or even encourages - this. The problem of apps needlessly requiring Administrator-level privileges is 100% the fault of the developers of said apps and has been for nigh-on a decade.

        Ironically Microsoft themselves have a proud history of producing such apps...

        There's nothing "weak" about Windows NT's security model. Never has been. There were, arguably, weaknesses in the *default configuration in some environments*, ...

        I agree, only I'd change *default configuration in some environments* to out-of-the-box defaults which are unchanged in most environments.
    • As you say, not exactly a security problem by MS (as explained). But encouraging more applications to install more services, seams like a bad idea, when the only reason to install it as a service is to get rid of UAC window every-time it is started. Obviously as every program starts installing a service, their will obviously be more in-secure windows systems, since once any of the new services can be hacked... It even sounds like you can't do stuff like *nix, IE assign a user/group to a application, that
  • In defense of Vista (never thought I'd write that!) It's my understanding that UAC is actually aimed at developers. There's a large ecosystem of Windows developers of varying quality, and Microsoft wanted to force them to write programs that behave correctly. Developers who were used to doing all sorts of system-level actions without considering security now have to contend with an inconvenient UAC warning, so they're forced (at least nominally) to try and find a way to do things within userspace as much
    • In defense of Vista (never thought I'd write that!) It's my understanding that UAC is actually aimed at developers.

      I agree. A few months ago I had a small and simple program which I really wanted to be able to run in a 'setuid' kind of way, and I discovered that I simply couldn't because under the UAC model Microsoft doesn't allow this. It was annoying at the time since I was already planning to separate the admin program I'd written from everything else. Instead I'd have to run the admin program as a se

  • a programmer is bitter that an OS forced him to separate privileged code from unprivileged. news at 11.
    • by tepples ( 727027 )
      No. As I understand the article, the programmer is bitter that Win32 code to perform separation was ten times bigger than the code to actually do anything.
  • http://blogs.msdn.com/oldnewthing/archive/2007/08/07/4268706.aspx [msdn.com]

    The big take away here is that this is not a security hole in any sense of the word. In order for a malware author to exploit this they would first have to get the user to install a service on the machine. If you can get the user to install random software, why bother with any other steps? You've already compromised the machine. I mean if your "security hack" involves the step "Get user to install malicious software", then you don't have a sec
  • You mean there is an easy way to code around those annoying [infoworld.com] Windows Vista privilege escalation dialog boxes??? Thanks god!!!
  • TFA is a pointless contradictory rant. First they say

    But getting this far wasn't easy. With Windows Vista, what should have been 100 lines of code maximum ended up being a dozen times longer, split across two different processes, and requiring way too much man-hours to write the most minimalist and to-the-point piece of software we've released to date.

    But then later they say

    Any program that UAC blocks from starting up "for good security reasons" can be coded to work around these limitations with (relativ

  • by taniwha ( 70410 )
    This is the United Aerospace Corp that runs those waste dumps around mars right - are they having security problems again? will they never learn?
  • I could be wrong, but the other alternative is to PAY MONEY to get a certificate and sign your code.

    I don't think the certificate lasts more than a year at a time either. Anyone writing free utilities that need privs isnt' going to want to spend several hundred $ a year to "certify" their sw...

  • Lies and FUD... (Score:2, Informative)

    I'm sorry, but Microsoft does NOT sell UAC as a "security framework" or a "security model" or even a security boundary, as the article claims. It's a convenience tool that makes it easier for you to run applications as standard user, that's IT. Anyone that claims UAC has ANYTHING to do with security has absolutely no clue what they're talking about -- and I challenge you to show me Microsoft documentation that speaks of UAC as a security boundary.

    From TFA: "Microsoft can claim that Vista blocks system-modif

"I am, therefore I am." -- Akira

Working...