Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Coding Around UAC's Security Limitations

kdawson posted more than 6 years ago | from the bounce-pass-out-of-bounds-while-the-ref-isn't-looking dept.

Security 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.'"

cancel ×

334 comments

Sorry! There are no comments related to the filter you selected.

Where have I heard this before? (4, Insightful)

fahrbot-bot (874524) | more than 6 years ago | (#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.

Re:Where have I heard this before? (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23217112)

A few years ago, while browsing around the library downtown, I had to take a piss. As I entered the john, a big beautiful all-American football hero type, about twenty five, came out of one of the booths. I stood at the urinal looking at him out of the corner of my eye as he washed his hands. He didn't once look at me. He was "straight" and married -- and in any case I was sure I wouldn't have a chance with him.

As soon as he left, I darted into the booth he'd vacated, hoping there might be a lingering smell of shit and even a seat still warm from his sturdy young ass. I found not only the smell but the shit itself. He'd forgotten to flush. And what a treasure he had left behind. Three or four beautiful specimens floated in the bowl. It apparently had been a fairly dry, constipated shit, for all were fat, stiff, and ruggedly textured. The real prize was a great feast of turd -- a nine inch gastrointestinal triumph as thick as a man's wrist. I knelt before the bowl, inhaling the rich brown fragrance and wondered if I should obey the impulse building up inside me. I'd always been a heavy rimmer and had lapped up more than one little clump of shit, but that had been just an inevitable part of eating ass and not an end in itself.

Of course I'd had jerkoff fantasies of devouring great loads of it (what rimmer hasn't?), but I had never done it. Now, here I was, confronted with the most beautiful five-pound turd I'd ever feasted my eyes on, a sausage fit to star in any fantasy and one I knew to have been hatched from the asshole of the world's handsomest young stud.

Why not? I plucked it from the bowl, holding it with both hands to keep it from breaking.

I lifted it to my nose. It smelled like rich, ripe limburger (horrid, but thrilling), yet had the consistency of cheddar. What is cheese anyway but milk turning to shit without the benefit of a digestive tract? I gave it a lick and found that it tasted better then it smelled. I've found since then that shit nearly almost does. I hesitated no longer. I shoved the fucking thing as far into my mouth as I could get it and sucked on it like a big brown cock, beating my meat like a madman. I wanted to completely engulf it and bit off a large chunk, flooding my mouth with the intense, bittersweet flavor. To my delight I found that while the water in the bowl had chilled the outside of the turd, it was still warm inside. As I chewed I discovered that it was filled with hard little bits of something I soon identified as peanuts. He hadn't chewed them carefully and they'd passed through his body virtually unchanged. I ate it greedily, sending lump after peanutty lump sliding scratchily down my throat. My only regret was the donor of this feast wasn't there to wash it down with his piss. I soon reached a terrific climax. I caught my cum in the cupped palm of my hand and drank it down. Believe me, there is no more delightful combination of flavors than the hot sweetness of cum with the rich bitterness of shit. Afterwards I was sorry that I hadn't made it last longer. But then I realized that I still had a lot of fun in store for me. There was still a clutch of virile turds left in the bowl. I tenderly fished them out, rolled them into my hankercheif, and stashed them in my briefcase.

In the week to come I found all kinds of ways to eat the shit without bolting it right down. Once eaten it's gone forever unless you want to filch it third hand out of your own asshole -- not an unreasonable recourse in moments of desperation or simple boredom.

I stored the turds in the refrigerator when I was not using them but within a week they were all gone.

The last one I held in my mouth without chewing, letting it slowly dissolve. I had liquid shit trickling down my throat for nearly four hours. I must have had six orgasms in the process. I often think of that lovely young guy dropping solid gold out of his sweet, pink asshole every day, never knowing what joy it could, and at least once did,bring to a grateful shiteater.

Re:Where have I heard this before? (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23217152)

Puts on tinfoil hat

Thankyou Steve Ballmer for that wonderful peice of literature to bring down the tone of a reasonable discussion about the problems with Vista.

Your resources would be better spent creating Aero for XP.

Re:Where have I heard this before? (4, Insightful)

dhavleak (912889) | more than 6 years ago | (#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!

Re:Where have I heard this before? (0)

Anonymous Coward | more than 6 years ago | (#23217340)

Not entirely BS, read. [washingtonpost.com] You can search and find much more info on government input into Vista. Real question would be what, if anything, is stamped SECRET?

Re:Where have I heard this before? (3, Informative)

dhavleak (912889) | more than 6 years ago | (#23217418)

1. OP said Homeland Security and TSA -- your link refers to NSA. There's a distinction there. NSA are security experts. DHS and TSA policies cause nothing but confusion and meaningless threat level colors.

2. The part in your link that nicely sums up NSA's contributions:

The NSA also declined to be specific but said it used two groups -- a "red team" and a "blue team" -- to test Vista's security. The red team, for instance, posed as "the determined, technically competent adversary" to disrupt, corrupt or steal information. "They pretend to be bad guys," Sager said. The blue team helped Defense Department system administrators with Vista's configuration.

I can't see anything wrong with that...

Re:Where have I heard this before? (0)

Anonymous Coward | more than 6 years ago | (#23217662)

fahrbot-bot said "Sounds like it was written by Homeland Security and the TSA." This was obviously intended as a jovial reference to the fact that these agencies work to give a false sense of security to many and thereby justify their reason for existance as the article implies for elements of Vista.

DHS was set up with the idea that it would accumulate input from the other alphabet soup agencies and put the information to use to "protect the USA". Microsoft seeking input from one of these alphabet soup agencies and the end results of the output as implied by the article easily could lead one to the same jovial thought that fahrbot-bot had on the subject in relation to the article. For all we know Microsoft asked the CIA for help too, only the CIA is having trouble getting information out of Vista after the waterboarding. (sense of humor test)

Re:Where have I heard this before? (4, Funny)

imbaczek (690596) | more than 6 years ago | (#23217368)

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:Where have I heard this before? (2, Insightful)

Sique (173459) | more than 6 years ago | (#23217372)

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.

Re:Where have I heard this before? (4, Informative)

dhavleak (912889) | more than 6 years ago | (#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.

Re:Where have I heard this before? (4, Insightful)

wwahammy (765566) | more than 6 years ago | (#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:Where have I heard this before? (2, Insightful)

Tony Hoyle (11698) | more than 6 years ago | (#23217380)

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:Where have I heard this before? (2, Insightful)

drsmithy (35869) | more than 6 years ago | (#23217486)

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 this different to any other platform ?

Re:Where have I heard this before? (2, Interesting)

peragrin (659227) | more than 6 years ago | (#23217606)

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 stuff that only I can run, and stuff that only I can see.

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.

Re:Where have I heard this before? (1)

wwahammy (765566) | more than 6 years ago | (#23217652)

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.

Re:Where have I heard this before? (3, Insightful)

drsmithy (35869) | more than 6 years ago | (#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 ?

Re:Where have I heard this before? (5, Insightful)

IchBinEinPenguin (589252) | more than 6 years ago | (#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.

Re:Where have I heard this before? (0)

Anonymous Coward | more than 6 years ago | (#23217396)

Maybe the gist of TFA, which I haven't R of course, is that UAC is no selinux, even if redmond could be tempted to market it as such.

Re:Where have I heard this before? (1)

dhavleak (912889) | more than 6 years ago | (#23217570)

Maybe if you RTFA you'll realize that isn't the gist of the article :)

Re:Where have I heard this before? (3, Insightful)

Anonymous Coward | more than 6 years ago | (#23217640)

Slashdot loses a little relevance and credibility every time a stupid post like this one is green lighted. Submitter should read before submitting.

Obligatory out-of-context movie quote (0, Troll)

HetMes (1074585) | more than 6 years ago | (#23217044)

I think I am going to have a heart attack from NOT being surprised!

Erratum... (0, Troll)

HetMes (1074585) | more than 6 years ago | (#23217058)

Damn, on further consideration, the quote should have been: I think I'm gonna have a heart attack and die from not surprise!

Must do better... (0)

Anonymous Coward | more than 6 years ago | (#23217054)

So, apart from DRM, what has Microsoft actually created new in Vista? looks like a lot of people have spent 5 years hanging around the water cooler.

Re:Must do better... (2, Funny)

somersault (912633) | more than 6 years ago | (#23217068)

Nah - musta taken them at least 4 years to get that 'glass' effect just right!

Re:Must do better... (2, Insightful)

Yvan256 (722131) | more than 6 years ago | (#23217098)

Negotiating contracts with ATI and nVidia for a share of videocard sales does take time, you know.

A Service... (4, Informative)

maz2331 (1104901) | more than 6 years ago | (#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... (4, Informative)

Gazzonyx (982402) | more than 6 years ago | (#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.

Re:A Service... (2, Insightful)

Dogun (7502) | more than 6 years ago | (#23217390)

Which is fine, provided the interfaces exposed by the daemon aren't themselves insecure.

Film at 11 (4, Funny)

symbolset (646467) | more than 6 years ago | (#23217072)

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... (4, Insightful)

argent (18001) | more than 6 years ago | (#23217074)

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:Much as I like seeing Microsoft humbled... (2, Insightful)

cheater512 (783349) | more than 6 years ago | (#23217504)

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

Uhm, no not really a UAC work-around ... (5, Informative)

Anonymous Coward | more than 6 years ago | (#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.

Easy, but it's Not, but it is? (5, Insightful)

Anonymous Coward | more than 6 years ago | (#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:Easy, but it's Not, but it is? (2, Insightful)

Sique (173459) | more than 6 years ago | (#23217292)

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.

Re:Easy, but it's Not, but it is? (0)

Anonymous Coward | more than 6 years ago | (#23217430)

In any case, the notion that it takes 1000 lines of code to write a service and some basic IPC is laughable. These are bog-standard tasks that are accomplished with well-documented Windows APIs, not some Herculean task for expert Windows hackers.

Re:Easy, but it's Not, but it is? (1, Interesting)

Anonymous Coward | more than 6 years ago | (#23218036)

There's a difference between being hard to a honest programmer to work around UAC and being hard for a malware programmer to do the same.

Honest, "good" programmers should have no trouble whatsoever with whatever security systems there are to work with. Those should be designed to trouble malware, not the "good" software.

Malware programmers, however, have the purpose to work around and find loopholes in security systems and thus it MUST be hard for them to operate under any security system. After all, malware is trying to do nasty stuff in your system.

What this article is stating is just the opposite. As a Software Developer you are bound to have lots of shit coming your way if you intend to work on Wista because of UAC limitations. As a malware programmer, you can just easily overcome the "difficulties" and live happily ever after.

The problem with journalism, I'd say, is that it looks honest, but just isn't. Sometimes, however, bloggers don't have the ability to be clear and concise.

A terrible idea. (1)

Kaenneth (82978) | more than 6 years ago | (#23217094)

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?

Too easy to fix? (0)

Anonymous Coward | more than 6 years ago | (#23217122)

I was under the impression that Microsoft wants developers to rework their code to use calls that don't require security elevation. The fact that performing these workarounds is "easy" sounds to be a good thing. After all, why would you want developers to have trouble adopting a new standard?

UAC is shite (1, Insightful)

syousef (465911) | more than 6 years ago | (#23217130)

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 own home. Microsoft has lost the plot in recent years. Changes to Office, a dud version of windows with almost nothing new and lots of DRM shite, changes to poiicy in everything from OS to Office to gaming. None of it friendly to the end user. They're large enough that the jury's out as to whether they'll sustain the hit or go down but they're making their systems undesirable to work with.

Re:UAC is shite (0)

Anonymous Coward | more than 6 years ago | (#23217842)

The phrase 'you can't have your cake and eat it too' comes to mind. I have been using Vista with UAC under a lower privileged account (so that I am prompted not just with a 'continue' button but with the password request) for over a year now and it's worked just fine for me. I see UAC as a way to protect my computer from others who use it. If they can't install a trojan without knowing the admin password I'm that much safer.

Disabling UAC completely is probably not a great idea. At the very least it warns you that something naughty is going to happen.

MS on a trainride to obscurity (0)

Anonymous Coward | more than 6 years ago | (#23218006)

Mod parent insightful.

BTW1 when I installed Microsoft Visual C++ 2003 on Vista it makes me explicitly start it in Administrator mode. That should tell you the design of UAC is broken.

BTW2 Given a choice between rewriting our apps for the latest version of Windows just to support the retarded Vista designers, or rewriting it for the web aka Google apps, guess which one I'd choose?

A privileged service is not a "hack." (5, Insightful)

w3woody (44457) | more than 6 years ago | (#23217132)

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.

Re:A privileged service is not a "hack." (1)

NaijaBobo (1280218) | more than 6 years ago | (#23217200)

Mod parent up. I signed up to slashdot for the first time to make this comment. And the rather negative tone saddens me. Perhaps we should however work towards easier coding interfaces that make this less of a challenge for the poor developer. -- uke Obligatory Disclaimer: I work for the criticized company.

Re:A privileged service is not a "hack." (2, Funny)

homesteader (585925) | more than 6 years ago | (#23217872)

Obligatory Disclaimer: I work for the criticized company.
So can you make Vista suck less? Please?

Re:A privileged service is not a "hack." (4, Informative)

vux984 (928602) | more than 6 years ago | (#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.

Re:A privileged service is not a "hack." (1)

cbart387 (1192883) | more than 6 years ago | (#23217284)

Thank you, I was going to say the identical thing.

Instead, I'll give an example. Certain operations of yum are restricted to root, such as the install option. If yum accepted the install option from a process running as a normal user it would be similar to what iReboot* is doing. It's not a security flaw of the OS. It IS a security flaw of the process/daemon to blindly be accepting normal user accounts privileged access...

Regardless, to get that privileged process running to 'circumvent UAC', don't you have to be privileged to begin with?

* Is anyone else getting tired of the iNames?

Re:A privileged service is not a "hack." (0, Troll)

cbart387 (1192883) | more than 6 years ago | (#23217342)

It IS a security flaw of the process/daemon to blindly be accepting normal user accounts privileged access...
Ignore that comment please, it's retarded without knowing particulars.

Re:A privileged service is not a "hack." (4, Informative)

LO0G (606364) | more than 6 years ago | (#23217454)

Actually I thought your comment was 100% accurate.

If I write a service that allows any user to write to any location in the filesystem (entirely possible on any OS - for Windows, I install a LocalSystem service, for *nix, I install a daemon that runs as root) then that service has a security hole in it, and it can be used to elevate privileges from normal user to admin/root.

That's a flaw in the service/daemon, not a flaw in the OS.

Unless you were saying that you don't know if this app has a security flaw like the one I described above.

Re:A privileged service is not a "hack." (1)

cbart387 (1192883) | more than 6 years ago | (#23217568)

Unless you were saying that you don't know if this app has a security flaw like the one I described above.
Right. I agree with your statement that it could be a potential route for subverting the system. My statement that "it is a security flaw" was a little too strong. Security risk yes, but not necessarily a security flaw. I was still on my 'yum install', where giving the normal user rights for that is obviously not a good idea.

Re:A privileged service is not a "hack." (2, Informative)

Tony Hoyle (11698) | more than 6 years ago | (#23217426)

Regardless, to get that privileged process running to 'circumvent UAC', don't you have to be privileged to begin with?

No, because MSI runs privileged and is able to install such processes at the command of normal users - that's the hole. You get one prompt, at installation time.. but I've never seen a windows installer that *didn't* prompt for elevation. Contrast with Unix based systems where installing apps as a normal user is the norm and installing as root is an exception (indeed with OSX each user has a full set of directories for this by default, and it's rare for something to require elevation.. when it does you definately think because it's unusual).

Re:A privileged service is not a "hack." (2, Insightful)

drsmithy (35869) | more than 6 years ago | (#23217548)

No, because MSI runs privileged and is able to install such processes at the command of normal users - that's the hole. You get one prompt, at installation time.. but I've never seen a windows installer that *didn't* prompt for elevation.

Nothing to do with the OS, everything to do with the application developer.

Contrast with Unix based systems where installing apps as a normal user is the norm and installing as root is an exception (indeed with OSX each user has a full set of directories for this by default, and it's rare for something to require elevation.. when it does you definately think because it's unusual).

Bullshit.

If you think the vast majority of UNIX applications aren't installed by root, to a system-wide location, or that the vast majority of OS X apps aren't installed to /Applications (also by root), then you're either a fool or delusional.

*Especially* today. You might just have had a point, ~20 years ago, when multiuser UNIX systems with technically competent users were at least relatively common, but today when most people interact with what are essentially (if not technically) single-user PCs, such a claim doesn't even pass the laugh test.

Re:A privileged service is not a "hack." (1)

TheRealSlimShady (253441) | more than 6 years ago | (#23217746)

Just because MSI runs privileged does not mean that standard users are able to install system processes. You get a prompt when you try to do so - if you are a local admin then the prompt says "are you sure" and if you're a standard user you get asked for admin credentials.

Re:A privileged service is not a "hack." (1)

Moridineas (213502) | more than 6 years ago | (#23217922)

Contrast with Unix based systems where installing apps as a normal user is the norm and installing as root is an exception (indeed with OSX each user has a full set of directories for this by default, and it's rare for something to require elevation.. when it does you definately think because it's unusual).
Wow..that's crazy! Using FreeBSD/OpenBSD I pretty much always elevate to root / use sudo to install applications or make system config changes (/etc). On OSX, I would say MOST installers require you to elevate. Apps that you install with drag+drop of course don't need elevation.

OSX actually does require you to type your password to elevate fairly often! The main difference, imho, between Vista and OSX is the Vista interface SUCKS, and you get asked to elevate MULTIPLE times during the same process. In OSX, it's never more than one time.

Re:A privileged service is not a "hack." (1)

ColdWetDog (752185) | more than 6 years ago | (#23217968)

* Is anyone else getting tired of the iNames?

i'M not

Re:A privileged service is not a "hack." (1)

Z34107 (925136) | more than 6 years ago | (#23217758)

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 prompts and everything) even limited or guest accounts can play all the Steam games.

Seems nobody reads style guides, or even checks MSDN anymore.

Not a novel idea... (0)

Anonymous Coward | more than 6 years ago | (#23217134)

I hope they're not going to try to patent the method - I used a similar method to get around a setuid() problem (whereby dropping a setuid program into the local uid meant it was unable to regain the "elevated", setuid, privilege again) in version 2.4 of a program I released on 20/06/1990: I fork()ed off a server process before dropping the uid of the process to that of the real user.

Re:Not a novel idea... (2, Interesting)

SL Baur (19540) | more than 6 years ago | (#23217610)

I used a similar method to get around a setuid() problem (whereby dropping a setuid program into the local uid meant it was unable to regain the "elevated", setuid, privilege again) in version 2.4 of a program I released on 20/06/1990: I fork()ed off a server process before dropping the uid of the process to that of the real user.
Obvious prior art. That technique has been used for decades.

This certainly fits with my experience (1, Redundant)

JMZero (449047) | more than 6 years ago | (#23217138)

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 communicate between the .NET control and the surrounding page (you can't, for example, just call a function on the page, despite the fact that you have full trust).

With that being the case, I tried editing a property on the control once it was finished uploading, but that too didn't work as the page couldn't read them (even properties like "height" that it could infer couldn't be read directly). I thought about some fairly complicated solutions involving polling using XMLHTTP, partial refreshes or scripting or something - but what I ended up doing was this:

1. When the page loads, take note of the position of two elements on the page.
2. Poll the position of these elements a few times each second.
3. When the upload control finishes, it increases its height by 4 or 5 pixels.
4. This displaces the other elements on the page, and this can be used as a signal that an upload is complete and a refresh should be done.

This ended up working fine, but I felt ridiculous for having done it this way. There's no security being added here - the control and the page can communicate all they want via the server or scripting (or 100 other ways), it just means that using the controls is much more difficult and obscure than it needs to be.

Re:This certainly fits with my experience (0)

Anonymous Coward | more than 6 years ago | (#23217238)

silverlight is great for this you can call client-side javascript from within a silverlight app to do this.

Re:This certainly fits with my experience (1)

gbjbaanb (229885) | more than 6 years ago | (#23217330)

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.

Re:This certainly fits with my experience (1)

maxume (22995) | more than 6 years ago | (#23217704)

That and you can rely on flash being installed a great deal more of the time than you can rely on a custom control(the OP was talking about an intranet, so presumably, their control is always available).

Re:This certainly fits with my experience (3, Informative)

TheRealMindChild (743925) | more than 6 years ago | (#23217350)

Dude. You just create an event in your control, and implement a scripted handler on the page. Not exactly rocket science.

More fud (5, Insightful)

ryan_hurst (1280216) | more than 6 years ago | (#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.

Re:More fud (0, Redundant)

Tony Hoyle (11698) | more than 6 years ago | (#23217446)

Except that on Vista *anyone* can install that application. On Unix you would need the root password to do such a thing.

Re:More fud (1)

nxtw (866177) | more than 6 years ago | (#23217526)

Except that on Vista *anyone* can install that application. On Unix you would need the root password to do such a thing.


Not entirely true. Anyone on Vista with administrator privileges can install that application. If the user does not have administrator rights on the machine, he or she will be see a password prompt for a proper admin account.

Anyone with root privileges (via sudo) on OS X or Unix can do the same thing.

Re:More fud (1)

ryan_hurst (1280216) | more than 6 years ago | (#23217560)

Not true, on Unix if you were running as a admin (root) you would not be prompted at all. The difference is that in VISTA the default user is a type of admin (for app compat reasons), you can think of that admin as a restricted admin, as a restricted admin they can become a full admin by going through the UAC consent experience. Now if you created a real standard user in VISTA and ran a program that required admin you would get a user id and password prompt, not a consent prompt; thats esentially the same think as windows saying oh for this action to work he needs to run su, lets run su for him so he doesnt ahve to figure that out on his own. Again like unix except the OS figured out the need for SU for you. The net net of all of this is the only differences between the two approaches are: 1. Even root needs to confirm changing system configuration, this is clearly a function of application compatability and having to deal with the history of Windows and its glutany of poorly designed applications (like the old iReboot) 2. Windows figures out the need for SU for you, again a function of the success/history of Windows and the associated needed usability/application compatability.

Re:More fud (1)

homesteader (585925) | more than 6 years ago | (#23217900)

Not sure about Linux, but in OS X you are prompted even when running as an admin. Admin != root

Re:More fud (1)

ryan_hurst (1280216) | more than 6 years ago | (#23217966)

On Unix admin=root, what Vista and OSX do are in essence the same thing though as I understand it in OSX its implemented at the application layer vs the os layer.

Re:More fud (1)

TheRealSlimShady (253441) | more than 6 years ago | (#23217770)

So that's twice now you've posted the same inaccurate information. On Vista, if you're a local admin, you have to accept that the change is going to happen (UAC prompt). If you're a standard user, you *cannot* install that application without providing administrative credentials (UAC prompt). Just like on Unix.

Re:More fud (1)

drsmithy (35869) | more than 6 years ago | (#23217786)

Except that on Vista *anyone* can install that application. On Unix you would need the root password to do such a thing.

False. Not on all, but certainly the majority of UNIX systems in use today.

Misleading Summary (4, Interesting)

Manip (656104) | more than 6 years ago | (#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.
 

Re:Misleading Summary (1)

darknb (1193867) | more than 6 years ago | (#23217466)

Did you RTFA? Because pretty much everything in the summary is in the article. I agree that this anti-UAC crap is FUD, but come on, the summary said nothing that wasn't in the article.

From the Article:
"With the current Windows Vista security models, Microsoft can claim that Vista blocks system-modification tools from running at startup; but the truth is, there are still many ways to get them to run. At the end of day, our experience with iReboot and Vista's security implementations brings us to the sad conclusion that with Windows Vista, Microsoft has made ISVs' jobs more complicated without actually providing any any further protection for end users from malware authors - which certainly isn't the best way of going about this task."

Obviously the summary was paraphrasing the conclusion for brevity's sake. How is the article 'fine' considering you just refuted its whole goddamn premise?

Re:Misleading Summary (0)

Anonymous Coward | more than 6 years ago | (#23217686)

Additionally, NeoSmart doesn't make free software.

They make proprietary software that they give away for no price.

Re:Misleading Summary (1)

Compuser (14899) | more than 6 years ago | (#23217894)

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.

To be perfectly honest, (1)

rmdir -r * (716956) | more than 6 years ago | (#23217178)

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.

Re:To be perfectly honest, (1)

Simon (S2) (600188) | more than 6 years ago | (#23217244)

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-frontend code he wrote :)

Sounds like security designed by DHS (0)

Anonymous Coward | more than 6 years ago | (#23217208)

Are you sure M$ didn't outsource the creation of their "for your own protection" vista security model to the Department of Hopeless Stupidity?

Hummm, looks impressive, costs you time and energy, can be circumvented easily and accomplishes nothing useful- yup thats security designed to be DHS compliant.

What a plonker (0)

Anonymous Coward | more than 6 years ago | (#23217222)

So the user is asked to install the service with full priv's, and then this service has.... full priv's? And this is a workaround?

Waste of space, move on... nothing to see here.

Am I missing something? (1)

glitch23 (557124) | more than 6 years ago | (#23217256)

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.

They got "around" UAC by creating a service that runs as a privileged account (default Windows services do the *exact* same thing already and so do many other 3rd party apps) with a UI which provides users the ability to communicate with that service. Exactly how is that getting around UAC? If you don't use a privileged service then you basically can't do anything that requires privileges so isn't this what the design is supposed to be to properly interact with UAC? Or am I missing something? Maybe these guys were just too used to coding up anything they wanted to get something working and now they have to do it more securely (and properly for that matter by splitting up their logic) and are just a little annoyed they had to spend some extra time doing it. Tons of other applications already do this so it is nothing new. Looks to me like they are doing exactly what they should be doing.

Stinging criticism, indeed. (0, Redundant)

ScrewMaster (602015) | more than 6 years ago | (#23217278)

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.

Ouch.

Weird logical disconnect in the article (5, Informative)

Mark Programmer (228585) | more than 6 years ago | (#23217302)

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.

Re:Weird logical disconnect in the article (1)

drsmithy (35869) | more than 6 years ago | (#23217442)

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

Vista does nothing to change anything fundamental in Windows's security, nor does it need to. It does introduce and improved UI and a bunch of hacks to work around broken applications, but that is because those applications are broken, not because there's a problem in Windows.

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.

There's nothing "weak" about Windows NT's security model. Never has been. There were, arguably, weaknesses in the *default configuration in some environments*, but this is a simple end-user issue and not something that should be mistaken for genuine and fundamental _design_ problems (like, for example, UNIX's superuser).

Re:Weird logical disconnect in the article (1)

Hucko (998827) | more than 6 years ago | (#23217672)

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?

Re:Weird logical disconnect in the article (3, Informative)

Tacvek (948259) | more than 6 years ago | (#23217986)

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:Weird logical disconnect in the article (2, Informative)

Mark Programmer (228585) | more than 6 years ago | (#23217874)

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 that it's easier for me to just run as administrator and ignore the issue altogether.

But I do have to ask whether this is totally the fault of the developers. I'm a developer myself, and I've experimented with running as a non-administrator. Simply being forced to "Run as..." most of my development applications was enough to make me want to re-enable administrator privileges on my personal account. But I was effectively forced to re-privilege myself when I began developing an IE plugin. If there is a way to register ActiveX controls with the system as a non-administrator so that Internet Explorer can find and use them correctly, I am unaware of it. IE's reliance on ActiveX means that you effectively can't download and install plugins from the Internet without admin rights---even in such a way that the execution of those plugins would be at a non-administrator privilege level.

Incidentally, Firefox sidesteps this entire issue by allowing plugins to be downloaded into a user's Application Data directory.

So the WindowsXP security model is fairly robust as a model. But with software written by Microsoft themselves not taking advantage of it in a way that makes the end user's life convenient, there's certainly something that smells. Even if the only real substantive difference between the Windows XP and Vista security models is the addition of a more convenient on-the-fly escalation mechanism, that's saying something.

(I don't know how my example of grabbing ActiveX plugins from the Internet works in Vista under UAC. If someone has experience with it, I'm interested)

Re:Weird logical disconnect in the article (3, Insightful)

IchBinEinPenguin (589252) | more than 6 years ago | (#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.

This is stupid. (0)

Anonymous Coward | more than 6 years ago | (#23217312)

That's the way it's supposed to work. You install a service that gets the heavy lifting done without requiring UAC prompts while a small user-mode application interacts with the service. You still get a UAC prompt when installing the service, so this is a non-issue.

reminds me of another silly security model... (0)

0WaitState (231806) | more than 6 years ago | (#23217314)

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

So that would make Vista's UAC the TSA of software security? (for the non-USians, TSA are the friendly folks who have us remove our shoes at airport security checkpoints, and require us to package all carryon liquids in 3 ounce containers in clear plastic baggies, among other acts of security theater)

Re:reminds me of another silly security model... (0)

Anonymous Coward | more than 6 years ago | (#23217458)

Actually, it would mean that you either didn't read, or didn't understand the original article, but kudos for blindly jumping on the bandwagon with the other sheeple.

Fitting captcha: "distorts".

-AC

Other purpose of UAC (1)

barryfandango (627554) | more than 6 years ago | (#23217320)

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 as possible.

"got around", yeah, right. (1)

imbaczek (690596) | more than 6 years ago | (#23217332)

a programmer is bitter that an OS forced him to separate privileged code from unprivileged. news at 11.

Reading this reminded me of this... (1)

dctoastman (995251) | more than 6 years ago | (#23217354)

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 security hole, you have stupid users.

Wait a minute.... (1)

prxp (1023979) | more than 6 years ago | (#23217408)

You mean there is an easy way to code around those annoying [infoworld.com] Windows Vista privilege escalation dialog boxes??? Thanks god!!!

What a load of bollocks (1)

rudy_wayne (414635) | more than 6 years ago | (#23217472)

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 (relative) ease.
Well, which is it? Is it hard or easy? It can't be both. More importantly, their "bypassing" of UAC requires the user to run an installer that requires admin privleges (and the UAC prompt that goes with it). WTF? How is that "bypassing" anything?

wow (1)

dodgedodge (166122) | more than 6 years ago | (#23217554)

So to "get around" the Vista security they had to install a service using admin privileges. Ok????

Beware of stupid windows programmers (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23217562)

Well... serves them right for missing the point completely.

1) Not everybody runs as and Administrator. There are people that are savvy about their computers AND their security - i.e. not running as Administrators and, gasp, possibly even using dual-boot.

2) If you make application that simply assumes that everybody runs as and Administrator and cry foul when suddenly your favorite OS provider comes to senses and makes you stop doing that, then you're simply a bad programmer. Bad, bad programmer.

3) Wow... what a concept: you make a privileged system component (device driver, service, daemon, ...) which is then accessed by unprivileged (userland) interfaces. If they worked around anything, it was basically just their own stupidity. Why do they blame some security put in place to prevent them from making the stupidity in the first place.

4) If they think they're high-tech, then they should look around. UNIX had been doing the same since at least '90s, after suddenly realizing that SUID root isn't always a good thing.

5) Maybe they should find something else to do. Your average Indian does better job than they ever thought possible.

Of course the last time UAC had security issues (1)

ross.w (87751) | more than 6 years ago | (#23217678)

It took a bad ass marine with a bunch of serious weaponry to fix it again.

Meh (1)

thetoadwarrior (1268702) | more than 6 years ago | (#23217710)

Microsoft has said that UAC is meant to be annoying to force developers to do things properly to avoid it.

Sounds like they're just doing things more on the proper side. I'm sure Vista isn't that secure but at least they've made some sort of effort even if it's poorly thought out.

Rather than have UAC come up and have the user simply ok anything that comes up. They should have stopped the program from running at all. Developers can just rely on users clicking ok because, as annoyed as they may get, most won't switch to Linux or even Mac. So where is the incentive not to annoy the customer?

UAC? (1)

taniwha (70410) | more than 6 years ago | (#23217782)

This is the United Aerospace Corp that runs those waste dumps around mars right - are they having security problems again? will they never learn?

Logical Error? (1)

daveisfera (832409) | more than 6 years ago | (#23217818)

Does it really make sense to spend so much talking about how big of a pain it makes coding for programmer, but then point out how easy it is for malware to get around it? Something about that just doesn't quite make sense.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>