New (to me) Windows Internets Security Feature
-
Okay, so, step by step, write me a script that registers a scheduled task running with admin privileges from a non-admin-launched executable.
Protip: the only thing that auto-elevates is the MMC snap-in. schtasks.exe requires elevation for /RL HIGHEST, and so do API calls.
-
Plus, if it were that easy we'd have seen an abolute metric ton of shitware exploiting such an oversight.
-
Treating documents from the Internet differently from documents from internal networks or USB drives is a dubious idea. Some would even say it's a bad idea.
Which is why documents from internal networks are (were?) treated just as suspiciously as those downloaded from the Internet, and there are plans to add removable drives to the list as well -- only SharePoint, OneDrive, and fixed drives will be considered safe, and I'm kinda suspicious about SharePoint staying on that list for long.I'm not sure how Office treats files with macros that don't come from the internet (I don't have it installed here)
Starting in 2007, the same way, unless you configure it not to prompt you. Which is an option not available for "Mark of the Internet"-ed documents, last I checked.
-
You know what else is insecure? Computers. Just think about it - running arbitrary code, with access not only to all API calls, but peripherals directly! The ability to execute code on a computer is a major security flaw and should never have been implemented.
I agree, which is why I view the whole IoT thing askance.
-
with access not only to all API calls, but peripherals directly!
On Linux, unprivileged users can't even access a serial port by default. You need to add them to the dialout group.
-
On Linux, unprivileged users can't even access a serial port by default. You need to add them to the dialout group.
But a malicious processor in tandem with a malicious hard drive can install Windows on themselves and gain access to the serial port! How do you fix that, huh?
-
@TimeBandit said:
On Linux, unprivileged users can't even access a serial port by default. You need to add them to the dialout group.
But a malicious processor in tandem with a malicious hard drive can install Windows on themselves and gain access to the serial port! How do you fix that, huh?
Duh. Run Linux hardware.
-
It was designed before the internet made file sharing easy.
So was Unix. Your point is ?
-
Okay, so, step by step, write me a script that registers a scheduled task running with admin privileges from a non-admin-launched executable.
Note that comment that states this still works in Windows 10 and kindly sod off.
-
Script uses a local administrator account to do local administration.
In equally shocking news, water is found to be wet.
-
But you should still get dinged by the Annoy-o-Tron 3000 that is UAC when doing local administration. Anything that uses the high half of the split token needs to get dinged, even if only to say "oh, Windows component, carry on...". This doesn't.
-
Because it's a scheduled task that may need to run while the computer's unattended.
Kinda pointless showing a UAC alert when the user thirty miles away, right?
-
Which is why when you put in the scheduled task definition "Launch elevated", you have to elevate to register it. Duh.
The issue is that the task launches elevated anyway even when you say "Whatever you do, don't launch elevated!!" and thus don't get a prompt.
-
How does the Task Manager know the task needs elevation without running it first?
-
Task Manager doesn't, but you're around to elevate if you need to.
Task Scheduler, you put it in the scheduled task definition file (
.job
or JobXML) ahead of time (the GUI does this automatically). If you said "elevate the task", then when you try to register it you're prompted to elevate at that point, so the task will be run elevated in the future. If the task needs to elevate, but you didn't say either way or said "don't elevate", then it should just silently fail with an Access Denied error, and did in Vista and 7. But on 8.1 and 10, it's launched fully elevated, no pre-prompting required.
-
Why do I get the feeling that's down to a Group Policy default change?
-
Even if It is, it seems potentially harmful...
-
Even if It is, it seems potentially harmful...
Well, not by much - you still opted to run code on a local admin account.
I agree that it should go ding when trying to register the task. But that's a bug, not an evidence of a broken security model.
-
I agree that it should go ding when trying to register the task. But that's a bug, not an evidence of a broken security model.
As originally implemented in Vista and per the spec at that time, this would be a major security bug. An admin's entire interaction was supposed to be no different than a standard user's, except that they could click "continue" in UAC rather than having to authenticate. Since a standard user couldn't register a task that'd be run with admin rights, neither should an admin without UAC.
Apparently, in Windows 8 the definition changed from
airtight hatchwaysecurity barrier to "oh yeah, that reminder thingamabob", so this is no longer considered - by Microsoft - a security breach, just a Task Scheduler bug. And we're just supposed to know that UAC is no longer keeping us safe and we shouldn't trust it when running as admin - which is still the default privilege level of the first account.I call bullshit and I still say it's a security breach.
-
which is still the default privilege level of the first account.
Wouldn't it have to be? Unless 1) non-privileged user can create privileged accounts (insecure) or 2) you can run fine without ever having an admin for the lifetime of the OS (unlikely)
You could create two accounts, one admin one non, but you can't do just a non-admin without weakening the security anyway.
-
I call bullshit and I still say it's a security breach.
It's a local admin creating a task that runs as local admin; to claim it's a security breach is like claiming code execution leading to code execution is a vulnerability
-
It's a unelevated local admin creating a task that runs as elevated local admin
You may say that's a distinction without a difference, but that's exactly what UAC was supposed to prevent, and UAC was a security barrier.
-
It wasn't. Kinda. Sorta. I don't think even MS knows at that point, but they get rather defensive when you accuse them of having a broken security boundary.
My guess is that they intended it to be, then when people started bitching about it being "intrusive" to their shitty workflows, they went "'know what, fuck you, if you don't want to be secure then go ahead and get pwned".
Filed under: windows would be three times as good if microsoft stopped listening to random idiots on the internet
-
Well, we have our own resident idiots on this very board who insist on running Windows without UAC enabled.
-
idiots on this very board who insist on running Windows without UAC enabled
That's an informed security tradeoff,
http://www.bmorebikes.com/wp-content/uploads/2011/04/2011-04-21-Bike-Stockton-Copy.jpgas opposed to pointless security theatre:
http://www.youtube.com/watch?v=_2vLtpVPqhI
-
qed