They do make sense. You're missing something critical in the argument.
> So what’s interesting is MS say that UAC isn’t a security boundary. Which is some users to admin.
This is incorrect. UAC is for already-admin users; it's not "some users to admin". The security boundary exists around standard users, not admin users.
This might not be what you like, which I totally get, but it does make sense. If you want a security boundary, don't create a user in the Administrators group.
> If you want a security boundary, don't create a user in the Administrators group.
As a user aren't you essentially forced to this to have a usable desktop experience? I mean, sure, there is a boundary.. but it's drawn rather carelessly around the entire stack.
That used to be the issue in the XP era, and is the reason why the transition is why UAC was so hated. But today you can have a very normal desktop experience without admin permissions.
You have to switch to your admin account for some settings and maybe half the time you are installing new software, but everyday stuff now works well without privileges
And commonly you don't switch to the admin account outside of entering the admin credentials when the UAC is displayed.
There are still too many applications that unnecessarily require admin credentials to do something (I'd love the system to report exactly what the app is trying to do) but it is a lot better than it used to be
Best way to protect windows at home is actually to have two accounts - one standard you login with and use day to day and another admin account you really never need to login as. Anytime you need to install something or get admin access a pop up asks for your admin account and password.
Basically this is the default way Linux works (not entirely the same but similar enough) with sudo. And the way that every corporate IT department runs windows.
Another advantage is that if some malicious app tries to access something it shouldn't you will immediately know as the admin pop up will trigger.
> this is the default way Linux works (not entirely the same but similar enough) with sudo
Kinda sorta. Here "not entirely the same but similar enough" means "doing the one major thing that Linux does not force you to do", namely, creating a whole separate user account just so that MS can make the braindead claim that a security boundary isn't being crossed when you enter admin permissions from an Administrator account. On a Linux system you only need to create one user account, and put it in the sudoers group, and Linux then properly treats every attempt to do something with sudo as crossing a security boundary and acts accordingly.
I think you are very confused about what sudo and being in the sudoers group does? sudo is just a command which lets you execute a command as another user. In the typical use case, it lets you execute a command as root rather than as your current user. For it to do anything useful you have to do exactly the same thing as you do on Windows: create a second unprivileged account and log into that instead of root.
Except root is that account. You're still crossing a user-boundary same as Windows. If you give your user CAP_SYS_ADMIN that's like putting them in the Administrators group.
I've been using a separate, local admin account and non-admin users for a while for friends and family.
There's not a lot a typical user does that requires admin. For the odd software that breaks Windows' conventions, it's usually enough to install it outside of Program Files.
Of course with the push towards Microsoft accounts for login, this might soon be difficult.
Really threw in a wrench in my day once when I realized guest accounts were disabled years ago, I just wanted to hand a laptop over to a 3 year old to watch paw patrol and to create a new user it was having me go through a Microsoft account flow complete with 3 security questions. I didn't feel any safer afterwards.
> it's usually enough to install it outside of Program Files
Meaning, in a user's home directory somewhere? That's even worse, because now that user has write access to the executables. Which makes it even easier for some nefarious piece of software to pwn those executables, since they don't even need to get root permission.
But the executable can still only run in the context it exists even if it is compromised. This is akin to SELinux...
You cannot compromise an executable run without permission and magically get Administrator or some higher privilege level without another exploit. Sure that specific user's data may be compromised but in the end the system remained secure.
Also keep in mind Microsoft by default has a ton of sandboxes and checks on those applications which will likely get caught as well should that compromised application try to access something it shouldn't.
I don't personally know of a mass security event involving Windows that cannot be chuaked up to failing to implement security updates. Sure Microsoft has some massive security issues but in general their track record isn't as bad as people try to make it out as.
There are enough reasons to hate windows without making up new ones.
I run my personal desktop as a non-admin user. Every now and then I need to provide creds to my admin account, but the majority of what I do does not require it.
Yeah, exactly. It really depends what you're doing. If you're doing software development as part of your job, that's obviously going to require admin privilege way more often than if you're answering emails.
Agree, but also you don’t need the entire session running as admin. I usually leave a terminal and IDE running as an admin user with the rest of the session low-priv. Obviously some security weaknesses there but it’s better than having a whole admin session.
Even doing extensive software development - including WSL, Docker, SQL Server, and other services needing low level access - Admin privileges usually only come up when installing, updating or uninstalling software.
Sure, if you want your ordinary non-admin user to have write access to the executables, which makes it a lot easier for some malicious piece of software to hack them since it no longer needs to get root permissions.
> Sure, if you want your ordinary non-admin user to have write access to the executables, which makes it a lot easier for some malicious piece of software to hack them since it no longer needs to get root permissions.
As if non-admins have no way to create a new executable and run those instead? Windows has a million ways to run code, both visibly and invisibly. Why would malware prefer to trash an executable that the user relies on for daily work and risk revealing its presence so quickly?
If malware is already running as you with the ability to write to your files, what does it gain by Trojaning your VSCode to do bad stuff instead of just doing the bad stuff directly?
> If you want a security boundary, don't create a user in the Administrators group.
Which makes no sense. The fact that a user is in the Administrators group does not mean every single action they take should automatically have root permissions, or that using the UAC prompt to get root permission for a particular action shouldn't be treated as crossing a security boundary. On my Linux system, the fact that my user is in the sudoers group doesn't mean Linux just throws up its hands and says, oh well, can't enforce any security boundary now for what that user does. MS is simply punting here. But of course Windows was never designed for security, and what braindead security it does offer was bolted on as an afterthought.
You're twisting what "makes sense" means here. What they're saying makes sense with respect to the current design. They have had a design with one sharp security boundary and maintained it... for decades. Their statement is entirely consistent with that, and in no way nonsensical. You're saying it "doesn't make sense" to mean "I think this is poor design, and there should be multiple layers of security boundaries", and you're obviously welcome to have that opinion, but that doesn't mean their disagreement implies their statement is nonsense.
I fail to see the fundamental difference with Linux you're talking about. Typically adding a user to the sudo/wheel group mean precisely that they can run whatever as the superuser (root). Once you're root, Bob's your uncle.
Sure you can tweak it to only allow certain commands, restrict it to another group, etc. Which would be equivalant to, in Windows, probably using another group(s) than Administrators and assign privilegas as appopriate.
I have a lot of unfavorable opinions of security fundamentals in Windows but you're barking up the wrong tree here.
From your other comment in this thread:
> The issue is not that people don't understand how MS defines what is and is not a security boundary.
I have a theory that there's basically two types of disagreements, disagreements on definitions, and disagreements on value systems.
In this case Microsoft values downplaying this issue, so when that is at the top of their value system their decisions should make sense following that.
Since this is just a pet theory I'm very interested to hear critiques on it.
Disagreements on definition are a little bit easier, because then you can just talk about the definitions and resolve your differences there... For example let's say IDK You're trying to sort out how to design a software system, and everyone is speaking in terms of design patterns, but they haven't yet spelled out the details of what those designed patterns are, then that could probably lead to a lot of confusion if when you say A I think of A', and another person is thinking of A''.
I like this. I first noticed this with gay marriage. Some would say "gay people should be able to do what they want and form 'civil unions' with all the tax and contractual benefits and requirements of marriage, but they shouldn't be able to get 'married'". For these people, it was all about the definition of a word.
Other people opposed gay marriage because it went against their values. No matter what you wanted to call it, they were opposed to gay people living together and sharing their lives.
I chose this example because it's the first time I noticed that some disagreements are about the definition of a word, and it's an especially clear example of that. It's silly how huge disagreements about a single word can become.
There are also people who disguise their value disagreement as a definition disagreement. This is a form of bad faith arguing.
> Some would say "gay people should be able to do what they want and form 'civil unions' with all the tax and contractual benefits and requirements of marriage, but they shouldn't be able to get 'married'".
> Other people opposed gay marriage because it went against their values.
This difference does not matter - the outcome was the same. Stop treating bigots with kid gloves.
I think there's another example around trans-vocabulary:
The analog of the 1st half is "I'm not going to stop you from cutting off your man bits, but don't expect me to call you a 'woman'. 'Trans woman' is ok because that's a new word, but 'woman' already has a meaning and don't try to change it."
The analog of the 2nd half is "You shouldn't do that because you're a man and you need to act like one." Or perhaps it's an affront to nature or the divine.
Some of this may be due to a desire to transform an illicit desire for authority ("I declare that I shall not pay out a bounty") into a legitimate contest ("this bug is not a bug because I desire to clarify our communal understanding of the concept of a bug...").
Difference between the first and second there is basically the dividing line between the gender-critical feminists and the conservatives, on this topic.
Sorry, this is not a value system disagreement. It's definitions, pure and simple. As I mentioned in my sibling comment, the definition (and thus boundary) has been pretty sharp and clear for decades: the user group. If you're a standard user, such as in the "Users" or "Guests" groups, you're behind the boundary. If you're in the "Administrators" group, you're already past it.
Yes, it is. The issue is not that people don't understand how MS defines what is and is not a security boundary. The issue is that MS's definition is for the benefit of MS, not for the benefit of the user. That's a value system disagreement.
> The issue is not that people don't understand how MS defines what is and is not a security boundary.
That's a communication failure, not a value system disagreement.
> The issue is that MS's definition is for the benefit of MS, not for the benefit of the user. That's a value system disagreement.
Just because two entities differ on their values that doesn't mean everything they disagree on is their values.
In this case, the fact that users and Microsoft differ on what constitutes a security boundary is 100% a definitional disagreement.
Now MS obviously has had their own values and reasons for not establishing other security boundaries people would like, and that is a value system disagreement. But even if their values agreed with yours and they hated the current design just like you, the fact of the matter would still be that user account groups are the boundaries in the current design, and that would still imply this isn't crossing a security boundary, making the disagreement on that definitional.
Socratic logic argues you must first agree on the meaning of terms and definitions. Next is determination of what the facts are. Lastly is logical arguments. Guess which part is the most difficult?
Religious logic is like this. It presupposes a greater mystery that has been partially revealed to us. It also presupposes that our fallible logic cannot on its own understand the truth. In other words it defines faith as believing in the greater truth even if the world and every one says we are foolish to believe in such fairy tales.
This assumes Microsoft being a singular entity with a single set of values (or even a single set of definitions), which I believe is an incorrect premise. It’s misleading to think of organizations as if they were a single mind. (Not to speak of the fact that it’s quite common even for singular minds to have inconsistent values and beliefs.)
I've learned that if you want bugs fixed in Windows, pay for professional support. Same as corporate-managed open source software. The real question is why people bother doing free security research work for Microsoft, instead of spending their intellectual energy making desktop Linux better.
> Both UAC and sudo are just OS level cookie dialog boxes
To be fair, that's misconstruing UAC and CredUI/Secure Desktop a little. There probably is merit in switching to an isolated desktop session when seeking consent, or user credentials, despite the fact that UAC/the AuthZ part within a user account has flaws. I think another issue is probably that most user's exposure to UAC is on machine's they're the sole user and administrator of; it's a different ballgame in enterprises where the end user is probably the least privileged principal logged into a particular PC.
Windows et al have Sandboxed apps, but which apps and which users should be allowed to do system-level confirmation type changes? iOS and Android are (for the most part) on single user devices, you still need some sort of AuthZ system to decide who and which apps can change what on multi-user systems.
I don't understand why moving to system designs that require exploitation of the accessibility layer to turn a device into something semi functional.
Those OS go out of the way preventing features that hinder usefulness of the devices. Such as recording phone calls. Allowing the blocking of network IP addresses and domains. While supplying monolithic integration that is limited to all but the OS maintainers.
Google dialer does not allow for integration of 3rd party contacts. It is built around Google remote storage. Apple Messenger doesn't allow for conversing with non Apple device users except for insecure text messaging while promoting cyber bullying with green vs blue text.
Another security and business risk of using Google or Apple for content storage with limited recourse when they lock out our accounts.
> We need to give up on the UAC/sudo/etc. style of user based privilege escalation and instead sandbox apps, not users, just like Android and iOS do.
> Those OS go out of the way preventing features that hinder usefulness of the devices.
But one isn't necessarily synonymous with the other.
Mac OS is slowly going in this direction. Their policy these days is that apps shouldn't be able to do dangerous things by default, but should have the ability to ask for any specific privilege, if and when they need it.
Instead of getting a generic "this app wants admin privileges" popup, you get a "this app wants access to the files in your Documents folder" popup. This makes a lot more sense, lets you deny specific permissions while allowing others, and actually tells the user what the app needs the privileges for.
The more dangerous the privilege, the more involved the setup process is. The most dangerous privilege of all, that of installing your own kernel extensions, which can do (almost) everything and are your final option when there's truly no API for what you need to do, is gated behind a reboot into recovery mode.
This is combined with new, more secure APIs, so that privilege escalation is often entirely unnecessary. For example, most things that were formerly accomplished via kernel drivers can now be done with sandboxed, userspace processes, and there are APIs like the photo picker, where the user picks what photos to share in a system-managed window, that require no extra privilege because the system knows that the user just clicked on a photo in the context of that app.
Recording phone calls is possible in principle. The reason that it is not available on some devices or in some regions is that there are legal requirements which manufacturers have to adhere to in order to get their devices certified, i.e. in some countries it is illegal to record phone calls, in others explicit permission needs to be given, reason for manufacturers to take the safe route w.r.t. liability and disable it in those countries too, or even globally.
In the case of Windows, a lot is about compatibility. You can design a different system, but then a lot of existing software that users care about won’t properly function on it anymore.
However, if you read the article, the vulnerability is enabled by a race condition in a Windows security component, so really just a bug here, even if Microsoft is trying to deflect from that.
There's a middle ground where apps are sandboxed but you're still in full control... But of course OS vendors will not allow that, so we're just daydreaming here.
Have you ever heard of an IOMMU? Talking to hardware is not a god mode cheat code. It's long been feasible to limit a drive's access to hardware it's supposed to manage. Why should I let my NVMe driver talk to my NIC? It shouldn't even be able to see plaintext disk sectors! If you're going to make sweeping statements about others being incorrect, it would behoove you to become familiar with the material.
You should, because it's not a good look for you. You're clearly speaking from ignorance. OS research has progressed a lot from what you learned 20 years ago or whatever.
You're clearly interested in operating systems. I hope you learn about them one day so you can contribute to one. You might want to start with, e.g. infiniband drivers, which somehow allow programs to communicate "directly" with hardware without having unlimited privilege. There's a lot more to OS design than a user/kernel dichotomy, and user mode can do more than you think.
Drivers can be whatever but their effect is usually global not for a specific user or app. So when you update, say, a graphics driver you are updating a shared resource used by everything in the system.
You can run that display driver in whatever security context you want be it “root” or its own constrained context but that doesn’t change the fact that other things in the system, running under their own security contexts, are feeding that driver stuff. And given there is generally only one display output, or sound output, or whatever, all things in the system have to use it for output, making it more privileged than the rest.
Whatever security context a display driver runs in, that context by requirement has to be more privileged than whatever context your browser or a calculator app runs in. To make changes to that shared display driver, you need to cross some kind of security boundary and it would be nice to make sure the user is who they say they are, they are allowed to do the requested action and they are made aware of the change. Thus methods like UAC and sudo.
I’m not sure how you can escape that. Removing sudo and UAC doesn’t change the fact that something wants to mess with a shared resource running with some kind of elevated privilege.
I used to openly hate the UAC box but now I do recognize it as a low cost, high-return feature that interrupts people to force them to recognize that something serious is about to happen. It probably works fine for families and small businesses where it gives non-technical people and opportunity to back out of whatever they were doing, especially if they didn't realize or intend to change something.
I'm kind of with Microsoft on this one: the administrator can do arbitrary things to the computer, film at 11. Is there a nuance that I'm missing that raises the severity of this?
See also Raymond Chen's summary of this class of attack:
My thought exactly. If someone is already able to replace arbitrary DLLs on the system (a precondition for this "exploit" to work), all bets are off, and their ability to bypass driver signatures is probably the least of your concerns.
In practice there's no good defence against this, but Windows is designed to protect itself against these kinds of attacks if all components work together. With secure boot + driver signature validation + DLL signature validation, you can't just run any code by putting it in a DLL file. You're not hacking any normal computer by replacing user32.dll with virus.dll.
Downgrade protection is quite a hard problem to solve without at least breaking the automatic recovery tools. In theory Microsoft could register the versions of every system file somewhere, sign+hash that, and store it some place secure, but then they'd need to deal with reverts of system components after a failed update or restored system images becoming unbootable.
In practice, I don't see the use case for this attack, though. You can just put a legitimate, signed driver with a known exploit inside your executable and load that. Microsoft chooses to keep unpatched, vulnerable drivers rather than break hardware support for millions of users.
I'm not by any means a security guru. I understand some basics, but I think I'm missing a conceptual model somewhere. What is it about Windows that makes it so damn hackable?
The problem is that windows was developed before security was important. No one has made the necessary investments to create a truly secure computing platform.
Ideally a secure computing platform would have reproducible builds built on public inspectable infrastructure like fdroid. It would also virtualize all untrusted applications in a sandbox and implement the least privilege model.
Today we have the worst security. There is unknown, probably untested and insecure code running at every ring, from the CPU's ME, to the UEFI components, to the OS 3rd party drivers.
SeL4 has a fully verified kernel but it doesn't do virtualization yet.
> The problem is that windows was developed before security was important.
I disagree. Plenty of systems have added security as an afterthought and were just fine for the effort.
The problem is most people just want to play video games. They don't care about security. They don't actually want security if it frustrates their efforts to play games or reduces the computing power available for the game.
Look at houses. We could have amazing high security locks everywhere if we wanted. We don't. We don't perceive ourselves as needing them. It turns out "tamper evident" is a decent level of security for the real world and allows homes to be partially secure while being totally livable.
> The problem is that windows was developed before security was important.
But wasn't that Windows rebuilt from the ground up as Windows NT, which had more advanced security features out of the box than basic Unix/Linux (allow/deny ACLs vs octal permissions, SAM database vs /etc/passwd flatfile, SIDs vs manually assigned/reusable UIDs)?
(And some other cool design features that never got used, like POSIX/OS2 subsystems being on equal footing as the "regular" Windows32 subsystem.)
> But wasn't that Windows rebuilt from the ground up as Windows NT
That was the 1990s. Windows security was transformed in the 2000s and then with Windows 10. I'm not sure it can be said to be more vulnerable than other OSes.
It’s definitely more vulnerable than macOS since macOS has more encompassing system protection (SIP), kernel extensions have been moved to user space (DriverKit and FSKit), and pervasive sandboxing.
Interesting, I might need to do some reading, but macOS was terrible for a long time, and seriously lagging behind windows when it came to security. They seemed to just be coasting on the fact that Apple as a platform simply wasn't targeted to anywhere near the extent Windows was.
They didn't even have an ASLR implementation for way too long IIRC.
Does macOS have any form of MAC yet, or do they just rely on sandboxing?
The same can be told of UNIX, lets not forget the first worm was targeted at UNIX systems, and the root cause keeps being a regular CVE in C and C++ projects.
Of course. A new secure computing platform would have to be built from scratch and from secure primitives that would not be backwards compatible with anything outside of virtualized emulation.
I like how you started out with a reasonable comment and then ended in a Hacker News word soup of random security memes. It’s like going, “the problem is Python is interpreted, and the design of its interpreter makes it difficult to optimize” and then following up with “this is why we need everyone to write their code in Rust and assembly. There’s this thing called Mojo that looks like Python and has the performance of Rust that we could use”. Like, ok, thanks for your insight? None of it is actually useful or relevant in answering the question.
> windows was developed before security was important
I disagree - At best you could say DOS was developed before users knew security was important... Microsoft has explicitly ignored security since DOS - because functionality sells better than security. Anyone who has worked with Unix systems has always understood just how much of a sieve Microsoft OSes are. Anyone with wisdom has said that about Windows from the very very beginning. Windows anti-virus has been a thing for a very long time.
If your prior is the number of extreme security vulnerabilities in one year - the implication is that there are lot of undiscovered extreme security vulnerabilities.
And competent WaaS (Weaponisation as a Service) now exists to quickly deploy exploits for obscure weaknesses or recently discovered weaknesses. Users and companies no longer have a few weeks grace before mass exploitation occurs.
Use Windows, get pwned. The counterfactual is difficult: it is hard to prove you haven't been pwned... Anti-virus defence is often too late (plenty of examples eh!).
I've seen very careful users/developers get caught out again and again.
Not to say Windows is alone. Routers and other end devices are just as bad. And Android doesn't appear great to me either.
> Ideally a secure computing platform would have reproducible builds built on public inspectable infrastructure like fdroid. It would also virtualize all untrusted applications in a sandbox and implement the least privilege model.
Also, be careful what you ask for. Such a system would likely require Secure Boot to be enabled a-la Android, complete with userspace detection of a system which does not have Secure Boot enabled, for DRM implementations similar to a game console. We're already close, but UEFI bugs, virtualization, hundreds of TPM variants, and bus attacks have left holes.
Can’t believe people have not pointed out the biggest reason of them all. Its the most widely deployed desktop os across rich targets (corporations). A lot of time and investment goes into cracking it.
Most of them are offering nothing more than an ssh or web service. Not really a great or fair comparison.
Linux on the desktop is the least secure option out of Windows and macOS, barring RHEL with it's SELinux policies which probably put it ahead of Windows and macOS as well.
And almost none of those bother doing things like checking driver signatures at all. You don't need to figure out hacks like "downgrading the OS to bypass signature validation logic" when you can `insmod` the moment you get admin/root permissions.
You could configure all manner of security settings on Linux, of course, but on most Linux distros they're all left unconfigured.
> There are more computers running Linux on this earth by orders of magnitude.
Yes, but most of them aren't running GNU and have signed boot with no ability to disable it. Very shallow victory. Could turn into FreeBSD tomorrow, and very little ground would be lost.
For a while apple had better security. Now it's more even, if you go by the 0day prices. There's not a lot of truly secure options unless you wanted to develop your own phone from the ground up.
Wait until all those regulations requiring apple to allow different app stores come online and then we will see how secure iOS is. The day Joe Clicks-A-Lot can follow a link in some random pig butchering scam email then “legally” sideload and run whatever crazy weird goop happens to be at other end will really put things to the test.
Because letting Susie Easy-To-Phish install anything and everything on her iPhone is going to make things very… interesting.
That being said, Joe and Susie can already do that on android right?
The prevalence of 3rd party kernel-level code is an important factor too. Lots of windows malware relies on a vulnerable 3rd party kernel driver at some point.
By comparison, 3rd party kernel modules are rare and looked down upon on Linux and outright banned on macOS.
To note, Windows isn't allowed to completely block third party kernel code.
I don't have the reference at hand but it was part of their various anti-trust fallout, as it would give them an unfair advantage regarding to their own products.
IANAL, but this seems more like a classic temper tantrum thrown by a big corp over reasonable legislation.
They could offer an API for security relevant scanning for EVERYONE, including their own antivirus software. But that would make the world better, and make the legislation look justified.
It's the exact same thing with the Google Maps integration on Google Search. They could offer an API and a selection of map provider to the user. That would make Google Search better for the user AND enable competition. Instead they threw a temper tantrum and disabled map integration entirely, so they can blame the EU.
I see your point, while also seeing it as a more complex situation.
APIs means Microsoft gets to dictate what products exist in the first place. We know security software is a use case, but if for instance VR vendors come up with a completely different use case, will the existing APIs be enough for them ? And what recourse do they have if Microsoft either doesn't give a damn, or purposefully drags their feet for whatever reason ?
> They could offer an API for security relevant scanning for EVERYONE, including their own antivirus software
I mean, they have _lots_ of APIs. You'll just never have as much control from usermode as you will from the kernel; what API would make you say "yep, don't need a driver now, can do security fine from user"?
Microsoft claims they need kernel level access to implement their paid for security product ( Windows defender while free for home use is not free for enterprise )
If they firmly believe that, then they cannot block other software from having the same access or it would be anti trust.
They could perhaps make it free and bundled in windows, but they don’t want to lose the enterprise funding.
The alternative to that is Android and IOS where we don't have full control over our own devices unless we jailbreak them, which itself breaks so many critical apps on the mobile device stores that it's frequently not worth it to root the device.
No - the problem here is moreso the sheer complexity of Windows and the variety of devs involved and the push for backwards compatibility.
There are multiple ways to set things up in Linux. You can use sudo, or you can have a separate root user.
I have not used Windows enough in recent years to know, but there may be differences in what you need to enter your admin password for, which may make users less suspicious when asked. On Linux distros I have used the only regular operation on a desktop that requires it are software installation and updates updates, which has a well defined UI and comes after a specific user action.
>but there may be differences in what you need to enter your admin password for, which may make users less suspicious when asked. On Linux distros I have used the only regular operation on a desktop that requires it are software installation and updates updates, which has a well defined UI and comes after a specific user action.
clearly you haven't seen all the projects on github where the instructions are "curl ... | sudo sh". Moreover, the security model behind sudo is so hilariously bad that it's trivial to get EoP[1]. UAC might have plenty of exploits (usually around auto-escalation), but at least they make an attempt at making it secure.
[1] tl;dr: modify $PATH to contain a bobbytrapped version of sudo that executes the command you want, plus whatever evil stuff you want.
It'd be a lot less easy if the OS didn't seem to require full privilege escalation for a lot of tasks you don't need that for in linux. One of the major problems that leads to escalation is poor separation of concerns
Just counting things I've personally seen, using "untrusted" userspace software and accessing a USB webcam. It's possible these particular examples are no longer true. I haven't been a windows user for about 15 years. But both surprised me quite a lot when I saw people I know do them and it seemed indicative of a systemic separation of concerns problem
> using "untrusted" userspace software and accessing a USB webcam
Windows only requires escalation for this if you want to install that userspace software to a non-user location,* or if you want to install a driver for the webcam.
If you just want to run the program, this is not required.
A long time ago, in the pre-Vista era, when running programs as administrator was the default, many programs would not work if they were not run as administrator. This is no longer case for programs written after Vista. From Vista onwards, older programs that assume admin rights and attempt to change admin-only files get their reads and writes redirected to a VirtualStore folder within the user's profile, so that the program still works without administrative permissions.
* The exception is with some installers where the UAC installer detection kicks in and demands escalation straight away, even before you select an installation location (which could be a user-writable location). Turning this off requires using the Group Policy Editor or the Registry Editor to flip the EnableInstallerDetection registry key.
Well, the main difference is that one you just click "yes" and the other you usually need to enter a password.
Then there is also polkit, which does something similar to sudo, but for a different usecase (authenticating unpriviledged process access to a priviledge process). Polkit to my knowledge can differentiate between actions to "always allow", "requires confirmation" (press yes) and "require password".
The main difference is that UAC is automatically triggered by the OS and takes over the whole display making it harder to fake/intercept. It’s trivial to put a fake sudo in someones PATH and steal their password
lol UAC is such a lazy shitshow of a security implementation…
A) there is no interception to be had. It’s a fucking “Yes I am Admin” single click a child could do unsupervised.
B) It requires training for the user to know that this is a special UAC mode. That’s high-motivation, high-knowledge user training. Pilots train to recognize unusual signs. Your grandma does not train to recognize what UAC looks like, why it would come up and when. UAC is the biggest cop out of a security excuse and Windows should be ashamed.
The exploit under discussion is an attack on Windows Update, it doesn't AFAICT involved running privileged code as the user. Also the default Windows user has been non-Administrator for many years now. It's true you can fool users into elevating a shell or whatever, but that's true for pretty much all platforms.
I'm happy to complain about Windows, but I will say their progress in converting their ecosystem to user-by-default with elevation prompt warnings has been impressive.
Especially when they had to drag their developer community kicking and screaming to it. (in Windows Vista ~2006)
Afaicr, there's also a neat bit where the lock screen and UAC prompt actually run under an entirely different, privileged and restricted session (than the normal one the user is interacting with and running programs in).
And that the desktops are securable objects[1], so processes in the default desktop can't snoop on what's going on in the winlogon desktop say when the UAC prompt is shown.
What makes you think that it's "so damn hackable"?
Also, this particular attack requires administrator privileges and bypasses a security boundary that doesn't even exist on e.g. Linux. Linux doesn't have driver signatures and root can easily install a new kernel module.
Just a quick look at 2024's CVEs, 0days for Windows is a security nightmare. Not singling out Windows specifically, but they have a lot.
Browsers only just recently patched browsers being able to be served javascript that scans local devices on 10.* and 192.168.* etc hitting IoT devices with exploits and payloads, hell even hitting open listening sockets on localhost and 0.0.0.0 -- that's cross platform, how many years did that go under the radar?
And now Windows is getting 'Recall' which will monitor and scan your every PC action to remember it for you using ML; I don't see that going back at all /s
>Browsers only just recently patched browsers being able to be served javascript that scans local devices on 10.* and 192.168.* etc hitting IoT devices with exploits and payloads, hell even hitting open listening sockets on localhost and 0.0.0.0 -- that's cross platform, how many years did that go under the radar?
Ironically windows was not hit by that, but the "secure"(?) operating systems of mac and linux were.
Windows isn't especially hackable, they've been taking security seriously and doing a decent job for at least a decade, and honestly these days it's a lot better than the alternatives.
Really the issue is because it's used on something like 95% of desktops. More eyes on windows means more bugs being found.
A lot better than the alternatives in terms of security?
Even if we only consider alternatives in wide use like ChromeOS or macOS, I wouldn't in any serious way consider Windows to be more secure. More compatible yes, but not more secure.
It has a significantly better security architecture than macOS, and Linux is a mess as far as desktop use goes. Can't speak to ChromeOS but I understand that's pretty locked down, and honestly that could possibly take the lead, although I was only really thinking of Linux, Mac and Windows.
Linux definitely exists in a weird limbo. While it can be secured to an extreme degree, most people aren't using Linux that way on personal devices. Especially on a desktop. ChromeOS is quite secure since it is so locked down, but imagine getting the average Linux user to like it.
Curious as to your rationale for the security architecture of macOS being inferior. Is it because of the way the security features are implemented that you lean that way? macOS has its warts, but it also has plenty of security features I'm not aware of Windows/NT having.
> Linux definitely exists in a weird limbo. While it can be secured to an extreme degree, most people aren't using Linux that way on personal devices.v
For sure. I think my minimal Alpine desktop with well defined SELinux policies is better than Windows or macOS, but most people are using Ubuntu or similar which doesn't have anything like that (AppArmor helps somewhat), and doesn't really have any of the security innovations macOS or Windows have.
> Curious as to your rationale for the security architecture of macOS being inferior. Is it because of the way the security features are implemented that you lean that way? macOS has its warts, but it also has plenty of security features I'm not aware of Windows/NT having.
I will say I'm a little out of date on new features macOS may have introduced, but back in the day I remember them not even having a proper ASLR implementation, no form of MAC, nothing even close to things like Windows Secure Desktop[1] etc. Microsoft had a well deserved horrible reputation, but they really put in a lot of effort to turn things around, and I think they succeeded but without getting due credit from most techies. Whereas Apple it seemed like were coasting on the fact that macs were not nearly as targeted as a platform.
Yep, the almost impenetrable security of the last few Xboxes shows that Microsoft does have it in them to architect a very secure platform, even against physical attacks, but they don't have the luxury of doing such a clean-slate design with Windows. They can almost never afford to break backwards compatibility and the Xbox approach of running each instance of legacy software in its own fully isolated virtual machine wouldn't really scale to a multitasking environment.
For those not keeping score, the Xbox One only recently got a very limited jailbreak a decade after release, that only works on old firmware and only allows access to the innermost level of sandboxing, with the outer system sandbox, hypervisor, bootloader and optical drive handshake remaining unbroken to this day.
It allows it's users to actually use their computer as a computer instead of a glorified phone.
MacOS nannies you left and right, preventing you from doing things you want to do because Apple says no.
Windows historically didn't have such restrictions because it's a desktop operating system and not a gimped phone. They're slowly being added, but it takes time to overhaul an entire architecture while maintaining backwards compatibility (which MacOS also doesn't care about at all).
Linux is of course far more "hackable" but there aren't as many computer illiterates using it.
LOL you should be upvoted as your comment perfectly captures the blind arrogance of the software industry.
When you call people computer illiterate, you are blind to the technocrat injustice imparted onto the general populace.
> The obnoxious behavior and obscure interaction that software-based products exhibit is institutionalizing what I call "software apartheid":”
> ― Alan Cooper, The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity
> “When programmers speak of "computer literacy," they are drawing red lines around ethnic groups, too, yet few have pointed this out.”
> ― Alan Cooper, The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity
You too can see the light and rise above the elitism of computer literacy. You know, there are many smart people that are too prideful to put up with what computer people demand as computer literacy. They suffer in silence, you will not have their loyalty, and they will switch to competing software the moment they are able to.
What? I never said being computer illiterate is bad. Plenty of fine people are computer illiterate. And plenty of fine people are fantastic at things I'll never be good at. That's fine.
- The EULA absolves Microsoft of any liability whatsoever. So they share in none of the risk. Imagine if physical items were like this: hit one bump and your pickup is destroyed. Scissors fall apart irreparably once they contact any material that's not paper.
- MS putting backwards compatibility (mainly done for business customers) above everything, at all costs. The peanut butter factory in Indiana that's been running WFW since '89 must never be inconvenienced, even if it means tens of thousands of people have to take their brand new computers to the shop (at their own cost!) multiple times per year because of spyware infections.
- Not valuing innovation. A culture where engineers are just a necessity to keep the money-making machine running. All the excitement was drained about the end of the '90s. They made a couple nominal hits with the Surface, Xbox, and Azure, not going to discount that.
In principle, there's something about Windows object system being much a much more complex abstraction than Unix's streams.
But the reality is not that. Windows is just surrounded by layers and layers of bad code with atrocious interfaces. Any architectural weakness doesn't even register.
Well the demo is showing a crossing of something that ms has defined to not be a real security boundary: "Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong isolated from the kernel boundary." [0]
On the Linux side, SELinux which sets guardrails on the root user at the kernel level is mandatory for protecting classified information. Thus, there is most certainly a security boundary between root, let alone regular users with "admin" groups/perms, and the kernel.
How can Windows, which is used all over the government, have a policy that admin users can do whatever they want with the kernel without it being a security vulnerability?
It's not as good as SELinux but you can limit the rights of admins with group policy so that they won't be able to install random drivers in the environments you speak of that need that boundary.
On the Windows side, loading arbitrary kernel code is an annoying process that involves disabling driver validation+dev mode and one or two reboots. If all components are working well, merely being an admin does not grant you arbitrary kernel access like it does on most Linux configs. You need to pay for/steal someone else's code signing certificate or reconfigure the target to boot into a special mode (that may require a Bitlocker recovery key). Nothing a malware author can't do, but like on the macOS "verify every binary" approach, a malicious actor can be blocked with a single certificate revocation at that point, no AV necessary.
As for groups, Windows has a variety of groups with a range of permissions (both local and over network shares). On home installs, the default user will have all of the permissions, kind of like on how most Linux installs have a single sudo/wheel user. Every kernel object has a different ACL that can be altered down to the user level. Furthermore, Windows differentiates between various permission levels ("browser content rendering process" vs "normal process" vs "admin process"), doing things like preventing keystroke insertion into higher privileged processes running under the same user account.
In office/corporate environments, the person interacting with the computer never gets admin permissions at all, so the admin/kernel boundary isn't relevant until a privilege escalation exploit is involved. Even IT administrators should almost never use real admin accounts; almost everything from changing passwords to reconfiguring permissions and settings can be done with assigning users to lower privilege groups or the right ACLs, not entirely unlike how Linux capabilities can be used to grant relatively low-power users permissions that normally only root can use.
Windows's security problem isn't unlike Linux's: it can be locked down securely, but you'll break tons of applications and you'll need to read through tons of obscure documentation before you can pull it off. Out-of-the-box Windows has a lot of security features that Linux lacks, but when it comes to unmanaged home computers owned and used by normal people, neither has any real protection boundary preventing kernel access in practice.
The concept that there is a root/superuser account that can do anything they like is quite a common one, but it is an OS design choice. Any user account is just an object in the operating system and one can as well design an OS that enforces certain rules against all user accounts, even if that means limiting superuser accounts.
Legitimate reasons I can think of would be for example to protect certain secrets even in the event of an administrator compromise (like a TPM) or just to prevent administrators from accidentally messing up their systems to an extent that they wouldn't boot. Another (more controversial) goal is to enforce DRM.
Anyways, that's exactly what Microsoft is attempting to do with Windows: the OS tries to prevent administrative accounts from interfering with the kernel/installing rootkits (for whatever reason).
Also note that it's always important in this discussion to differentiate between administrative user accounts (in the OS) and "administrators" (people) with physical/hardware access.
It's also interesting how on both Windows and Linux normal-privilege local accounts are, practically, root equivalent. In Linux, we train people to type "sudo" in front of anything system relevant. On Windows, we train users to click through UAC prompts. When was the last time sudo said "no" to somebody for a reason other than a password typo?
(UAC is marginally better than sudo: UAC is system managed UI, while sudo is just a program. An attacker can plug in a malicious shell alias for sudo and steal your password.)
IMHO, it'd be more convenient for users and more reflective of actual security posture to get rid of both sudo and UAC (in the default setup of course) and stop pretending that there's a firm security boundary between root and the primary human local user account.
I think an equivalent way to phrase this that feels very different is:
"On both Windows and Linux the default installed users are, practically, root equivalent". I guess on the basis that the user performing the installation should be in control of the system (I mean, they are; they could've just not done the installation. Where are your access controls now, blank system!)
> When was the last time sudo said "no" to somebody for a reason other than a password typo?
Sudo doesn't say no to people, much like UAC doesn't say "no" to people. In both cases, people (admins) are meant to say "no" when they don't expect to be performing an administrative operation. People who are not admins and yet need to do such operations need an administrator to authorise it.
In both cases, if it's not a single-person system, whoever is setting the machine up should be setting up limited accounts for regular use.
On Linux, most modern user-facing applications are using polkit instead of sudo. You can actually just use pkexec instead of sudo in the terminal as well.
Instead of just running arbitrary commands as root, applications can use specific pre-defined actions like "org.freedesktop.udisks2.filesystem-mount". This shows a nice localized message to the end user about what the app is trying to do, so they can decide whether to allow it or not. The system administrator can also configure certain actions to not even require authentication, useful for e.g. flatpak updates, or to block certain actions altogether.
In my experience (on Gnome at least), Linux is moving towards Windows-style sudo protection. It lacks the "press ctrl+alt+delete to verify" trick.
Windows has the advantage that you don't need to script everything. You can wrap `runas`/`System.Management.Automation.PSCredential` around every other tool if you want to, you just don't need to in most cases.
On Linux, I do not install sudo, because I do not need very often to become root, and when I need that I usually want to do multiple operations.
I believe that "sudo" is useful only on multi-user computers (including company-owned and company-managed computers), where the administrator may want to give to some users the power to do only a restricted set of privileged operations.
I always use a different user account than root, mainly not for security, but to avoid any accidental mistakes, when I could delete or overwrite other files than intended.
I believe that this is a good enough reason to justify the need to type infrequently a password in order to change roles.
So the kernel is enforcing file sharing rules (mandatory locking, in effect) by scanning on open all open file handles for conflicting mandatory locks, but doesn't check for memory mappings of these files with conflicting permissions. Oops. Seems like a straightforward fix though.
It's worth noting that Linux just got rid of its last vestige of mandatory locking. Now you can write a loaded executable without getting EBUSY. Interesting how exactly the same feature on one OS can be a load bearing part of the security infrastructure and on another OS legacy crud to be deleted.
Seems like the attack is suspiciously simple: Fool the update process into installing old versions of kernel components with known vulnerabilities. I'm no expert, but surely MS has already thought about this and has a blacklist or revocation facility or whatever?
Is the root cause here an OS design issue or just a process failure where they failed to note the broken/bad hashes in the correct spot? The latter is much easier to fix, but the (slightly spun, as always) security announcement seems to claim the former.
Wow! I remember the hard time we all had at [1] (doing deep packet inspection drivers for [2]). when Microsoft first required driver signing in Windows. The workflow seemed, at first glance, even tougher than getting an app approved on the Apple Store, with documentation that was far from clear. Personally, this feels like a huge setback considering the resources companies have poured into complying with Microsoft’s requirements, only to see it exploited in this way. Of course, vulnerabilities are always out there, but it would have been reassuring if someone had uncovered this one earlier. Kudos to Alon Leviev and SafeBreach for discovering it.
it also allows tampering with Windows 11 to actually make it a better OS because it bypasses all the Microsoft lockdown bullshit, but let's focus on the rootkits instead.
I've noticed that a surprising number of people here on HN are in favour of locking down Windows and preventing any kernel access at all to Windows users. It reeks of the "think of the children" arguments.
As a user who does have need for kernel access, because it's my god damn system and not yours, Microsoft's or anybody else's, I don't want it locked down.
It's called security in depth. That means you don't need to prevent all kernel access for users, because there are layers of defense.
"heh, nice argument. unfortunately, in my head I have already depicted you as the seething pathetic baby bird and myself as the smug and unflappable red angry bird"
So what’s interesting is MS say that UAC isn’t a security boundary. Which is some users to admin.
Then they say admin to kernel (in this case) isn’t a security boundary.
While also saying that driver signing enforcement is a security feature.
Which is what’s being bypassed here.
But they claim in this case it’s not crossing a security boundary.
Please make sense.
> Please make sense.
They do make sense. You're missing something critical in the argument.
> So what’s interesting is MS say that UAC isn’t a security boundary. Which is some users to admin.
This is incorrect. UAC is for already-admin users; it's not "some users to admin". The security boundary exists around standard users, not admin users.
This might not be what you like, which I totally get, but it does make sense. If you want a security boundary, don't create a user in the Administrators group.
> If you want a security boundary, don't create a user in the Administrators group.
As a user aren't you essentially forced to this to have a usable desktop experience? I mean, sure, there is a boundary.. but it's drawn rather carelessly around the entire stack.
That used to be the issue in the XP era, and is the reason why the transition is why UAC was so hated. But today you can have a very normal desktop experience without admin permissions.
You have to switch to your admin account for some settings and maybe half the time you are installing new software, but everyday stuff now works well without privileges
And commonly you don't switch to the admin account outside of entering the admin credentials when the UAC is displayed.
There are still too many applications that unnecessarily require admin credentials to do something (I'd love the system to report exactly what the app is trying to do) but it is a lot better than it used to be
I actually like UAC.
Specially when it asks me if I should allow HP printer driver to download new updates. No thanks I'll keep the minimal driver Mr. HP.
For sure, denying unexpected UAC popups is a rather satisfying reflex at this point.
Best way to protect windows at home is actually to have two accounts - one standard you login with and use day to day and another admin account you really never need to login as. Anytime you need to install something or get admin access a pop up asks for your admin account and password.
Basically this is the default way Linux works (not entirely the same but similar enough) with sudo. And the way that every corporate IT department runs windows.
Another advantage is that if some malicious app tries to access something it shouldn't you will immediately know as the admin pop up will trigger.
> this is the default way Linux works (not entirely the same but similar enough) with sudo
Kinda sorta. Here "not entirely the same but similar enough" means "doing the one major thing that Linux does not force you to do", namely, creating a whole separate user account just so that MS can make the braindead claim that a security boundary isn't being crossed when you enter admin permissions from an Administrator account. On a Linux system you only need to create one user account, and put it in the sudoers group, and Linux then properly treats every attempt to do something with sudo as crossing a security boundary and acts accordingly.
I think you are very confused about what sudo and being in the sudoers group does? sudo is just a command which lets you execute a command as another user. In the typical use case, it lets you execute a command as root rather than as your current user. For it to do anything useful you have to do exactly the same thing as you do on Windows: create a second unprivileged account and log into that instead of root.
Except root is that account. You're still crossing a user-boundary same as Windows. If you give your user CAP_SYS_ADMIN that's like putting them in the Administrators group.
I've been using a separate, local admin account and non-admin users for a while for friends and family.
There's not a lot a typical user does that requires admin. For the odd software that breaks Windows' conventions, it's usually enough to install it outside of Program Files.
Of course with the push towards Microsoft accounts for login, this might soon be difficult.
Really threw in a wrench in my day once when I realized guest accounts were disabled years ago, I just wanted to hand a laptop over to a 3 year old to watch paw patrol and to create a new user it was having me go through a Microsoft account flow complete with 3 security questions. I didn't feel any safer afterwards.
> it's usually enough to install it outside of Program Files
Meaning, in a user's home directory somewhere? That's even worse, because now that user has write access to the executables. Which makes it even easier for some nefarious piece of software to pwn those executables, since they don't even need to get root permission.
But the executable can still only run in the context it exists even if it is compromised. This is akin to SELinux...
You cannot compromise an executable run without permission and magically get Administrator or some higher privilege level without another exploit. Sure that specific user's data may be compromised but in the end the system remained secure.
Also keep in mind Microsoft by default has a ton of sandboxes and checks on those applications which will likely get caught as well should that compromised application try to access something it shouldn't.
I don't personally know of a mass security event involving Windows that cannot be chuaked up to failing to implement security updates. Sure Microsoft has some massive security issues but in general their track record isn't as bad as people try to make it out as.
There are enough reasons to hate windows without making up new ones.
> I don't personally know of a mass security event involving Windows that cannot be chuaked up to failing to implement security updates.
The recent global ClownStrike outage?
I run my personal desktop as a non-admin user. Every now and then I need to provide creds to my admin account, but the majority of what I do does not require it.
Depends what you're doing?
Using any non Microsoft software.
Like what? Chrome? Firefox? Acrobat? Photoshop?
I’m the only local admin on my mother’s laptop, she’s never noticed and I’ve not logged in to do anything in over 2 years.
Yeah, exactly. It really depends what you're doing. If you're doing software development as part of your job, that's obviously going to require admin privilege way more often than if you're answering emails.
Agree, but also you don’t need the entire session running as admin. I usually leave a terminal and IDE running as an admin user with the rest of the session low-priv. Obviously some security weaknesses there but it’s better than having a whole admin session.
Even doing extensive software development - including WSL, Docker, SQL Server, and other services needing low level access - Admin privileges usually only come up when installing, updating or uninstalling software.
Only problem is that certain things update constantly (VSCode)
> Only problem is that certain things update constantly (VSCode)
Can't you just install it at the user level? https://code.visualstudio.com/docs/setup/windows#_user-setup...
> Can't you just install it at the user level?
Sure, if you want your ordinary non-admin user to have write access to the executables, which makes it a lot easier for some malicious piece of software to hack them since it no longer needs to get root permissions.
> Sure, if you want your ordinary non-admin user to have write access to the executables, which makes it a lot easier for some malicious piece of software to hack them since it no longer needs to get root permissions.
As if non-admins have no way to create a new executable and run those instead? Windows has a million ways to run code, both visibly and invisibly. Why would malware prefer to trash an executable that the user relies on for daily work and risk revealing its presence so quickly?
If malware is already running as you with the ability to write to your files, what does it gain by Trojaning your VSCode to do bad stuff instead of just doing the bad stuff directly?
> If you want a security boundary, don't create a user in the Administrators group.
Which makes no sense. The fact that a user is in the Administrators group does not mean every single action they take should automatically have root permissions, or that using the UAC prompt to get root permission for a particular action shouldn't be treated as crossing a security boundary. On my Linux system, the fact that my user is in the sudoers group doesn't mean Linux just throws up its hands and says, oh well, can't enforce any security boundary now for what that user does. MS is simply punting here. But of course Windows was never designed for security, and what braindead security it does offer was bolted on as an afterthought.
> Which makes no sense.
You're twisting what "makes sense" means here. What they're saying makes sense with respect to the current design. They have had a design with one sharp security boundary and maintained it... for decades. Their statement is entirely consistent with that, and in no way nonsensical. You're saying it "doesn't make sense" to mean "I think this is poor design, and there should be multiple layers of security boundaries", and you're obviously welcome to have that opinion, but that doesn't mean their disagreement implies their statement is nonsense.
I fail to see the fundamental difference with Linux you're talking about. Typically adding a user to the sudo/wheel group mean precisely that they can run whatever as the superuser (root). Once you're root, Bob's your uncle.
Sure you can tweak it to only allow certain commands, restrict it to another group, etc. Which would be equivalant to, in Windows, probably using another group(s) than Administrators and assign privilegas as appopriate.
I have a lot of unfavorable opinions of security fundamentals in Windows but you're barking up the wrong tree here.
From your other comment in this thread:
> The issue is not that people don't understand how MS defines what is and is not a security boundary.
With all due respect, check your assumptions...
This is a value system disagreement.
I have a theory that there's basically two types of disagreements, disagreements on definitions, and disagreements on value systems.
In this case Microsoft values downplaying this issue, so when that is at the top of their value system their decisions should make sense following that.
Since this is just a pet theory I'm very interested to hear critiques on it.
Disagreements on definition are a little bit easier, because then you can just talk about the definitions and resolve your differences there... For example let's say IDK You're trying to sort out how to design a software system, and everyone is speaking in terms of design patterns, but they haven't yet spelled out the details of what those designed patterns are, then that could probably lead to a lot of confusion if when you say A I think of A', and another person is thinking of A''.
I like this. I first noticed this with gay marriage. Some would say "gay people should be able to do what they want and form 'civil unions' with all the tax and contractual benefits and requirements of marriage, but they shouldn't be able to get 'married'". For these people, it was all about the definition of a word.
Other people opposed gay marriage because it went against their values. No matter what you wanted to call it, they were opposed to gay people living together and sharing their lives.
I chose this example because it's the first time I noticed that some disagreements are about the definition of a word, and it's an especially clear example of that. It's silly how huge disagreements about a single word can become.
There are also people who disguise their value disagreement as a definition disagreement. This is a form of bad faith arguing.
> Some would say "gay people should be able to do what they want and form 'civil unions' with all the tax and contractual benefits and requirements of marriage, but they shouldn't be able to get 'married'".
> Other people opposed gay marriage because it went against their values.
This difference does not matter - the outcome was the same. Stop treating bigots with kid gloves.
I think your example is accurate.
I think there's another example around trans-vocabulary:
The analog of the 1st half is "I'm not going to stop you from cutting off your man bits, but don't expect me to call you a 'woman'. 'Trans woman' is ok because that's a new word, but 'woman' already has a meaning and don't try to change it."
The analog of the 2nd half is "You shouldn't do that because you're a man and you need to act like one." Or perhaps it's an affront to nature or the divine.
Some of this may be due to a desire to transform an illicit desire for authority ("I declare that I shall not pay out a bounty") into a legitimate contest ("this bug is not a bug because I desire to clarify our communal understanding of the concept of a bug...").
Difference between the first and second there is basically the dividing line between the gender-critical feminists and the conservatives, on this topic.
> This is a value system disagreement.
Sorry, this is not a value system disagreement. It's definitions, pure and simple. As I mentioned in my sibling comment, the definition (and thus boundary) has been pretty sharp and clear for decades: the user group. If you're a standard user, such as in the "Users" or "Guests" groups, you're behind the boundary. If you're in the "Administrators" group, you're already past it.
That's all there is to it.
I see what you're saying...
I think the sibling comment accidentally put it better.
> There are also people who disguise their value disagreement as a definition disagreement.
Or maybe even more to the point: they are twisting their definitions to support their values.
I think we can agree on this.
>> There are also people who disguise their value disagreement as a definition disagreement.
> Or maybe even more to the point: they are twisting their definitions to support their values. I think we can agree on this.
I take it you're insinuating I'm one of these people here?
Hasn't group membership been the defining security boundary in Windows for over two decades?
> this is not a value system disagreement.
Yes, it is. The issue is not that people don't understand how MS defines what is and is not a security boundary. The issue is that MS's definition is for the benefit of MS, not for the benefit of the user. That's a value system disagreement.
> The issue is not that people don't understand how MS defines what is and is not a security boundary.
That's a communication failure, not a value system disagreement.
> The issue is that MS's definition is for the benefit of MS, not for the benefit of the user. That's a value system disagreement.
Just because two entities differ on their values that doesn't mean everything they disagree on is their values.
In this case, the fact that users and Microsoft differ on what constitutes a security boundary is 100% a definitional disagreement.
Now MS obviously has had their own values and reasons for not establishing other security boundaries people would like, and that is a value system disagreement. But even if their values agreed with yours and they hated the current design just like you, the fact of the matter would still be that user account groups are the boundaries in the current design, and that would still imply this isn't crossing a security boundary, making the disagreement on that definitional.
Socratic logic argues you must first agree on the meaning of terms and definitions. Next is determination of what the facts are. Lastly is logical arguments. Guess which part is the most difficult?
Religious logic is like this. It presupposes a greater mystery that has been partially revealed to us. It also presupposes that our fallible logic cannot on its own understand the truth. In other words it defines faith as believing in the greater truth even if the world and every one says we are foolish to believe in such fairy tales.
I think that's helpful for me and my theory. Informed by Socrates I will refine my theory. O:-)
There's three forms of disagreements.
1. Disagreements on definitions
2. Disagreements on facts
Kind of hard to disagree on logical implications
3. Disagreements on value systems
Not to be dense, which is most difficult?
This assumes Microsoft being a singular entity with a single set of values (or even a single set of definitions), which I believe is an incorrect premise. It’s misleading to think of organizations as if they were a single mind. (Not to speak of the fact that it’s quite common even for singular minds to have inconsistent values and beliefs.)
It makes sense if Microsoft's strategy is having a flexible self-serving value system.
I've learned that if you want bugs fixed in Windows, pay for professional support. Same as corporate-managed open source software. The real question is why people bother doing free security research work for Microsoft, instead of spending their intellectual energy making desktop Linux better.
They have always had these contradictions. I think it's because they know there are lots of bypasses for all of them.
UAC in practice doesn't function as a security boundary, and to make it one would so inconvenience users that they'd just go to other OSes.
Both UAC and sudo are just OS level cookie dialog boxes. Let's get rid of all three.
We need to give up on the UAC/sudo/etc. style of user based privilege escalation and instead sandbox apps, not users, just like Android and iOS do.
> UAC in practice
UAC is not a security boundary by design.
> It’s important to be aware that UAC elevations are conveniences and not security boundaries …
- Mark Russinovich, Microsoft Corporation [1]
[1] https://web.archive.org/web/20080101143433/http://www.micros...
> Both UAC and sudo are just OS level cookie dialog boxes
To be fair, that's misconstruing UAC and CredUI/Secure Desktop a little. There probably is merit in switching to an isolated desktop session when seeking consent, or user credentials, despite the fact that UAC/the AuthZ part within a user account has flaws. I think another issue is probably that most user's exposure to UAC is on machine's they're the sole user and administrator of; it's a different ballgame in enterprises where the end user is probably the least privileged principal logged into a particular PC.
Windows et al have Sandboxed apps, but which apps and which users should be allowed to do system-level confirmation type changes? iOS and Android are (for the most part) on single user devices, you still need some sort of AuthZ system to decide who and which apps can change what on multi-user systems.
I don't understand why moving to system designs that require exploitation of the accessibility layer to turn a device into something semi functional.
Those OS go out of the way preventing features that hinder usefulness of the devices. Such as recording phone calls. Allowing the blocking of network IP addresses and domains. While supplying monolithic integration that is limited to all but the OS maintainers.
Google dialer does not allow for integration of 3rd party contacts. It is built around Google remote storage. Apple Messenger doesn't allow for conversing with non Apple device users except for insecure text messaging while promoting cyber bullying with green vs blue text.
Another security and business risk of using Google or Apple for content storage with limited recourse when they lock out our accounts.
> We need to give up on the UAC/sudo/etc. style of user based privilege escalation and instead sandbox apps, not users, just like Android and iOS do.
> Those OS go out of the way preventing features that hinder usefulness of the devices.
But one isn't necessarily synonymous with the other.
Mac OS is slowly going in this direction. Their policy these days is that apps shouldn't be able to do dangerous things by default, but should have the ability to ask for any specific privilege, if and when they need it.
Instead of getting a generic "this app wants admin privileges" popup, you get a "this app wants access to the files in your Documents folder" popup. This makes a lot more sense, lets you deny specific permissions while allowing others, and actually tells the user what the app needs the privileges for.
The more dangerous the privilege, the more involved the setup process is. The most dangerous privilege of all, that of installing your own kernel extensions, which can do (almost) everything and are your final option when there's truly no API for what you need to do, is gated behind a reboot into recovery mode.
This is combined with new, more secure APIs, so that privilege escalation is often entirely unnecessary. For example, most things that were formerly accomplished via kernel drivers can now be done with sandboxed, userspace processes, and there are APIs like the photo picker, where the user picks what photos to share in a system-managed window, that require no extra privilege because the system knows that the user just clicked on a photo in the context of that app.
Recording phone calls is possible in principle. The reason that it is not available on some devices or in some regions is that there are legal requirements which manufacturers have to adhere to in order to get their devices certified, i.e. in some countries it is illegal to record phone calls, in others explicit permission needs to be given, reason for manufacturers to take the safe route w.r.t. liability and disable it in those countries too, or even globally.
In the case of Windows, a lot is about compatibility. You can design a different system, but then a lot of existing software that users care about won’t properly function on it anymore.
However, if you read the article, the vulnerability is enabled by a race condition in a Windows security component, so really just a bug here, even if Microsoft is trying to deflect from that.
There's a middle ground where apps are sandboxed but you're still in full control... But of course OS vendors will not allow that, so we're just daydreaming here.
>sandbox apps
This is about drivers...
1) drivers should be apps too (Redox and others (even macOS partially) get this right)
2) driver vulnerabilities are there regardless of user setup. Making a user click a UAC button doesn't make the vulnerability disappear
>drivers should be apps too (Redox and others (even macOS partially) get this right)
Man i stop here since you don't even know what a driver is, and no, nor Redox or macOS can do anything against a bad/hostile but signed driver.
But you obviously don't know what drivers are (hint..communicating directly with hardware)
Have you ever heard of an IOMMU? Talking to hardware is not a god mode cheat code. It's long been feasible to limit a drive's access to hardware it's supposed to manage. Why should I let my NVMe driver talk to my NIC? It shouldn't even be able to see plaintext disk sectors! If you're going to make sweeping statements about others being incorrect, it would behoove you to become familiar with the material.
[flagged]
> Hey i stop here,
You should, because it's not a good look for you. You're clearly speaking from ignorance. OS research has progressed a lot from what you learned 20 years ago or whatever.
You're clearly interested in operating systems. I hope you learn about them one day so you can contribute to one. You might want to start with, e.g. infiniband drivers, which somehow allow programs to communicate "directly" with hardware without having unlimited privilege. There's a lot more to OS design than a user/kernel dichotomy, and user mode can do more than you think.
>infiniband drivers, which somehow allow programs to communicate "directly" with hardware
At least you understand what drivers do, like my printer-driver or GPU-Drivers
Drivers can be whatever but their effect is usually global not for a specific user or app. So when you update, say, a graphics driver you are updating a shared resource used by everything in the system.
You can run that display driver in whatever security context you want be it “root” or its own constrained context but that doesn’t change the fact that other things in the system, running under their own security contexts, are feeding that driver stuff. And given there is generally only one display output, or sound output, or whatever, all things in the system have to use it for output, making it more privileged than the rest.
Whatever security context a display driver runs in, that context by requirement has to be more privileged than whatever context your browser or a calculator app runs in. To make changes to that shared display driver, you need to cross some kind of security boundary and it would be nice to make sure the user is who they say they are, they are allowed to do the requested action and they are made aware of the change. Thus methods like UAC and sudo.
I’m not sure how you can escape that. Removing sudo and UAC doesn’t change the fact that something wants to mess with a shared resource running with some kind of elevated privilege.
> Thus methods like UAC and sudo.
UAC and Sudo are pretty different when you actually compare their implementations and not just purpose.
Sudo is just a text prompt, UAC's design includes an entire isolated desktop to ensure fake prompts and such can't happen.
Check Hurd's daemons and Plan9/9front (and Hurd's) namespaces.
I used to openly hate the UAC box but now I do recognize it as a low cost, high-return feature that interrupts people to force them to recognize that something serious is about to happen. It probably works fine for families and small businesses where it gives non-technical people and opportunity to back out of whatever they were doing, especially if they didn't realize or intend to change something.
I'm kind of with Microsoft on this one: the administrator can do arbitrary things to the computer, film at 11. Is there a nuance that I'm missing that raises the severity of this?
See also Raymond Chen's summary of this class of attack:
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
My thought exactly. If someone is already able to replace arbitrary DLLs on the system (a precondition for this "exploit" to work), all bets are off, and their ability to bypass driver signatures is probably the least of your concerns.
In practice there's no good defence against this, but Windows is designed to protect itself against these kinds of attacks if all components work together. With secure boot + driver signature validation + DLL signature validation, you can't just run any code by putting it in a DLL file. You're not hacking any normal computer by replacing user32.dll with virus.dll.
Downgrade protection is quite a hard problem to solve without at least breaking the automatic recovery tools. In theory Microsoft could register the versions of every system file somewhere, sign+hash that, and store it some place secure, but then they'd need to deal with reverts of system components after a failed update or restored system images becoming unbootable.
In practice, I don't see the use case for this attack, though. You can just put a legitimate, signed driver with a known exploit inside your executable and load that. Microsoft chooses to keep unpatched, vulnerable drivers rather than break hardware support for millions of users.
I'm not by any means a security guru. I understand some basics, but I think I'm missing a conceptual model somewhere. What is it about Windows that makes it so damn hackable?
The problem is that windows was developed before security was important. No one has made the necessary investments to create a truly secure computing platform.
Ideally a secure computing platform would have reproducible builds built on public inspectable infrastructure like fdroid. It would also virtualize all untrusted applications in a sandbox and implement the least privilege model.
Today we have the worst security. There is unknown, probably untested and insecure code running at every ring, from the CPU's ME, to the UEFI components, to the OS 3rd party drivers.
SeL4 has a fully verified kernel but it doesn't do virtualization yet.
> The problem is that windows was developed before security was important.
I disagree. Plenty of systems have added security as an afterthought and were just fine for the effort.
The problem is most people just want to play video games. They don't care about security. They don't actually want security if it frustrates their efforts to play games or reduces the computing power available for the game.
Look at houses. We could have amazing high security locks everywhere if we wanted. We don't. We don't perceive ourselves as needing them. It turns out "tamper evident" is a decent level of security for the real world and allows homes to be partially secure while being totally livable.
> The problem is that windows was developed before security was important.
But wasn't that Windows rebuilt from the ground up as Windows NT, which had more advanced security features out of the box than basic Unix/Linux (allow/deny ACLs vs octal permissions, SAM database vs /etc/passwd flatfile, SIDs vs manually assigned/reusable UIDs)?
(And some other cool design features that never got used, like POSIX/OS2 subsystems being on equal footing as the "regular" Windows32 subsystem.)
> But wasn't that Windows rebuilt from the ground up as Windows NT
That was the 1990s. Windows security was transformed in the 2000s and then with Windows 10. I'm not sure it can be said to be more vulnerable than other OSes.
It’s definitely more vulnerable than macOS since macOS has more encompassing system protection (SIP), kernel extensions have been moved to user space (DriverKit and FSKit), and pervasive sandboxing.
Interesting, I might need to do some reading, but macOS was terrible for a long time, and seriously lagging behind windows when it came to security. They seemed to just be coasting on the fact that Apple as a platform simply wasn't targeted to anywhere near the extent Windows was.
They didn't even have an ASLR implementation for way too long IIRC.
Does macOS have any form of MAC yet, or do they just rely on sandboxing?
The same can be told of UNIX, lets not forget the first worm was targeted at UNIX systems, and the root cause keeps being a regular CVE in C and C++ projects.
Of course. A new secure computing platform would have to be built from scratch and from secure primitives that would not be backwards compatible with anything outside of virtualized emulation.
When that worm was created Windows did not exist.
And yet the root cause for it still hasn't been fixed in UNIX systems.
If you consider plan9/9front Unix 2.0, they did with namespaces.
Namespaces have nothing to do with buffer overflows.
I like how you started out with a reasonable comment and then ended in a Hacker News word soup of random security memes. It’s like going, “the problem is Python is interpreted, and the design of its interpreter makes it difficult to optimize” and then following up with “this is why we need everyone to write their code in Rust and assembly. There’s this thing called Mojo that looks like Python and has the performance of Rust that we could use”. Like, ok, thanks for your insight? None of it is actually useful or relevant in answering the question.
> windows was developed before security was important
I disagree - At best you could say DOS was developed before users knew security was important... Microsoft has explicitly ignored security since DOS - because functionality sells better than security. Anyone who has worked with Unix systems has always understood just how much of a sieve Microsoft OSes are. Anyone with wisdom has said that about Windows from the very very beginning. Windows anti-virus has been a thing for a very long time.
If your prior is the number of extreme security vulnerabilities in one year - the implication is that there are lot of undiscovered extreme security vulnerabilities.
And competent WaaS (Weaponisation as a Service) now exists to quickly deploy exploits for obscure weaknesses or recently discovered weaknesses. Users and companies no longer have a few weeks grace before mass exploitation occurs.
Use Windows, get pwned. The counterfactual is difficult: it is hard to prove you haven't been pwned... Anti-virus defence is often too late (plenty of examples eh!).
I've seen very careful users/developers get caught out again and again.
Not to say Windows is alone. Routers and other end devices are just as bad. And Android doesn't appear great to me either.
UNIX entire security model is "ambient security" in operating systems literature.
Ambient security is a joke. Real security requires a capability-based model.
seL4[0] implements the mechanisms to do this efficiently. Lions OS implements an entire system with seL4 as core[1] leveraging these mechanisms.
0. https://sel4.systems/About/seL4-whitepaper.pdf
1. https://trustworthy.systems/projects/LionsOS/
First I've heard of LionsOS. It is mature enough to run a web server: https://sel4.systems/Info/Website/
Check 9front and GNU/Hurd. Namespaces are good too.
>GNU/Hurd
It will not go anywhere until they manage to move away from the gnu mach kernel.
(as it hasn't happened yet, I am afraid it is quite unlikely to happen anymore)
> windows was developed before security was important
That was a long time ago, the 1980s and 1990s. Windows has been transformed since then, particularly with Windows 10.
>SeL4 has a fully verified kernel but it doesn't do virtualization yet.
It very much does virtualization. And, as far as I am aware, it does it better than any other OS.
Incidentally, seL4 just had its seL4 Summit 2024[0].
0. https://www.youtube.com/playlist?list=PLtoQeavghzr0ZntMmRPwg...
But is the virtualization component fully verified?
There are a few talks on VMM.
The major shortcoming right now is that guests only get one CPU, but as per the talks guest SMP is a priority and will be available in 3-4 months.
I do not follow the verification side much, but what I know is that VMM has some interesting properties.
Namely, VMM itself (which handles VM exceptions) does not get more capabilities than the VM, thus dramatically limiting usefulness of a VM escape.
> Ideally a secure computing platform would have reproducible builds built on public inspectable infrastructure like fdroid. It would also virtualize all untrusted applications in a sandbox and implement the least privilege model.
Also, be careful what you ask for. Such a system would likely require Secure Boot to be enabled a-la Android, complete with userspace detection of a system which does not have Secure Boot enabled, for DRM implementations similar to a game console. We're already close, but UEFI bugs, virtualization, hundreds of TPM variants, and bus attacks have left holes.
Can’t believe people have not pointed out the biggest reason of them all. Its the most widely deployed desktop os across rich targets (corporations). A lot of time and investment goes into cracking it.
There are more computers running Linux on this earth by orders of magnitude.
>> Its the most widely deployed desktop os across rich targets
>There are more computers running Linux
You did not address the claim you replied to. Users get compromised, and users use windows desktop.
The number of DB clusters or whatever running *nix isn't relevant.
Most of them are offering nothing more than an ssh or web service. Not really a great or fair comparison.
Linux on the desktop is the least secure option out of Windows and macOS, barring RHEL with it's SELinux policies which probably put it ahead of Windows and macOS as well.
And almost none of those bother doing things like checking driver signatures at all. You don't need to figure out hacks like "downgrading the OS to bypass signature validation logic" when you can `insmod` the moment you get admin/root permissions.
You could configure all manner of security settings on Linux, of course, but on most Linux distros they're all left unconfigured.
> There are more computers running Linux on this earth by orders of magnitude.
Yes, but most of them aren't running GNU and have signed boot with no ability to disable it. Very shallow victory. Could turn into FreeBSD tomorrow, and very little ground would be lost.
You forgot servers.
That’s what they’re talking about?
[flagged]
For a while apple had better security. Now it's more even, if you go by the 0day prices. There's not a lot of truly secure options unless you wanted to develop your own phone from the ground up.
GrapheneOS has been doing a lot of great work in the secure mobile OS space.
How about iPhone in lockdown mode?
Fuck, you should consult Apple.
I wonder how Jeff fucking Bezos didn't think of that one.
holy shit. what if Apple just shipped all phones in lockdown mode?
brb job offers
Wait until all those regulations requiring apple to allow different app stores come online and then we will see how secure iOS is. The day Joe Clicks-A-Lot can follow a link in some random pig butchering scam email then “legally” sideload and run whatever crazy weird goop happens to be at other end will really put things to the test.
Because letting Susie Easy-To-Phish install anything and everything on her iPhone is going to make things very… interesting.
That being said, Joe and Susie can already do that on android right?
[flagged]
The prevalence of 3rd party kernel-level code is an important factor too. Lots of windows malware relies on a vulnerable 3rd party kernel driver at some point.
By comparison, 3rd party kernel modules are rare and looked down upon on Linux and outright banned on macOS.
Apple has blessed some external kexts so they aren't outright banned, just very restricted.
To note, Windows isn't allowed to completely block third party kernel code.
I don't have the reference at hand but it was part of their various anti-trust fallout, as it would give them an unfair advantage regarding to their own products.
PS: an analysis of that situation during the Crowdstrike issue, with the relevant bits of the EU ruling: https://www.computerweekly.com/news/366598838/Why-is-CrowdSt...
IANAL, but this seems more like a classic temper tantrum thrown by a big corp over reasonable legislation.
They could offer an API for security relevant scanning for EVERYONE, including their own antivirus software. But that would make the world better, and make the legislation look justified.
It's the exact same thing with the Google Maps integration on Google Search. They could offer an API and a selection of map provider to the user. That would make Google Search better for the user AND enable competition. Instead they threw a temper tantrum and disabled map integration entirely, so they can blame the EU.
I see your point, while also seeing it as a more complex situation.
APIs means Microsoft gets to dictate what products exist in the first place. We know security software is a use case, but if for instance VR vendors come up with a completely different use case, will the existing APIs be enough for them ? And what recourse do they have if Microsoft either doesn't give a damn, or purposefully drags their feet for whatever reason ?
> They could offer an API for security relevant scanning for EVERYONE, including their own antivirus software
I mean, they have _lots_ of APIs. You'll just never have as much control from usermode as you will from the kernel; what API would make you say "yep, don't need a driver now, can do security fine from user"?
There’s two parts to it.
Microsoft claims they need kernel level access to implement their paid for security product ( Windows defender while free for home use is not free for enterprise )
If they firmly believe that, then they cannot block other software from having the same access or it would be anti trust.
They could perhaps make it free and bundled in windows, but they don’t want to lose the enterprise funding.
What might be enough is to have windows required to boot in a “install” mode before 3rd party kernel code can be added.
Not banned, you just have to go through some hoops to enable installation of third party kernel extensions
The driver signing blacklist file DriverSiPolicy.p7b had not been updated for years. It took a CERT analyst (Will Dormann) to ask why in 2022. It's being updated regularly now, but WTF. https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...
From my experience, it's that users are administrators by default. And it is super easy to convince them, to run anything with elevated permissions.
The alternative to that is Android and IOS where we don't have full control over our own devices unless we jailbreak them, which itself breaks so many critical apps on the mobile device stores that it's frequently not worth it to root the device.
No - the problem here is moreso the sheer complexity of Windows and the variety of devs involved and the push for backwards compatibility.
As if most linux users aren't also in the sudo group?
If you want to include anyone with an android device as a linux user then most of them are not.
At this point few besides the pedantic or motivated seem to want this, given that they've been massively diverged projects for at least half a decade
There are multiple ways to set things up in Linux. You can use sudo, or you can have a separate root user.
I have not used Windows enough in recent years to know, but there may be differences in what you need to enter your admin password for, which may make users less suspicious when asked. On Linux distros I have used the only regular operation on a desktop that requires it are software installation and updates updates, which has a well defined UI and comes after a specific user action.
>but there may be differences in what you need to enter your admin password for, which may make users less suspicious when asked. On Linux distros I have used the only regular operation on a desktop that requires it are software installation and updates updates, which has a well defined UI and comes after a specific user action.
clearly you haven't seen all the projects on github where the instructions are "curl ... | sudo sh". Moreover, the security model behind sudo is so hilariously bad that it's trivial to get EoP[1]. UAC might have plenty of exploits (usually around auto-escalation), but at least they make an attempt at making it secure.
[1] tl;dr: modify $PATH to contain a bobbytrapped version of sudo that executes the command you want, plus whatever evil stuff you want.
Reserve shells are indeed simple in *nix
It'd be a lot less easy if the OS didn't seem to require full privilege escalation for a lot of tasks you don't need that for in linux. One of the major problems that leads to escalation is poor separation of concerns
What action requires admin escalation on Windows but not on Linux?
Just counting things I've personally seen, using "untrusted" userspace software and accessing a USB webcam. It's possible these particular examples are no longer true. I haven't been a windows user for about 15 years. But both surprised me quite a lot when I saw people I know do them and it seemed indicative of a systemic separation of concerns problem
> using "untrusted" userspace software and accessing a USB webcam
Windows only requires escalation for this if you want to install that userspace software to a non-user location,* or if you want to install a driver for the webcam.
If you just want to run the program, this is not required.
A long time ago, in the pre-Vista era, when running programs as administrator was the default, many programs would not work if they were not run as administrator. This is no longer case for programs written after Vista. From Vista onwards, older programs that assume admin rights and attempt to change admin-only files get their reads and writes redirected to a VirtualStore folder within the user's profile, so that the program still works without administrative permissions.
* The exception is with some installers where the UAC installer detection kicks in and demands escalation straight away, even before you select an installation location (which could be a user-writable location). Turning this off requires using the Group Policy Editor or the Registry Editor to flip the EnableInstallerDetection registry key.
Is that different from sudo?
Well, the main difference is that one you just click "yes" and the other you usually need to enter a password.
Then there is also polkit, which does something similar to sudo, but for a different usecase (authenticating unpriviledged process access to a priviledge process). Polkit to my knowledge can differentiate between actions to "always allow", "requires confirmation" (press yes) and "require password".
The main difference is that UAC is automatically triggered by the OS and takes over the whole display making it harder to fake/intercept. It’s trivial to put a fake sudo in someones PATH and steal their password
lol UAC is such a lazy shitshow of a security implementation…
A) there is no interception to be had. It’s a fucking “Yes I am Admin” single click a child could do unsupervised.
B) It requires training for the user to know that this is a special UAC mode. That’s high-motivation, high-knowledge user training. Pilots train to recognize unusual signs. Your grandma does not train to recognize what UAC looks like, why it would come up and when. UAC is the biggest cop out of a security excuse and Windows should be ashamed.
> lol UAC is such a lazy shitshow of a security implementation…
It's by far the most secure and well thought out implementation of an elevation prompt across all operating systems.
A lot of thought went into designing the Secure Desktop [1] used by UAC, and really mac and linux not having something similar is an embarrassment.
[1] https://learn.microsoft.com/en-us/archive/blogs/uac/user-acc...
Sure I guess, I don't know why UAC gets so much hate while sudo gets so much praise.
UAC is strictly better than sudo IMO.
Does UAC solve security for windows? Of course not, but we were comparing against sudo here.
The exploit under discussion is an attack on Windows Update, it doesn't AFAICT involved running privileged code as the user. Also the default Windows user has been non-Administrator for many years now. It's true you can fool users into elevating a shell or whatever, but that's true for pretty much all platforms.
I'm happy to complain about Windows, but I will say their progress in converting their ecosystem to user-by-default with elevation prompt warnings has been impressive.
Especially when they had to drag their developer community kicking and screaming to it. (in Windows Vista ~2006)
Afaicr, there's also a neat bit where the lock screen and UAC prompt actually run under an entirely different, privileged and restricted session (than the normal one the user is interacting with and running programs in).
Ref: https://learn.microsoft.com/en-us/windows/security/applicati...
Apparently now termed the "secure desktop", it's transparently overlaid on top of the user desktop whenever you see a prompt.
It's not a transparent overlay, it's a completely separate desktop with a screenshot of the user desktop as its background. Really clever.
And that the desktops are securable objects[1], so processes in the default desktop can't snoop on what's going on in the winlogon desktop say when the UAC prompt is shown.
[1]: https://learn.microsoft.com/en-us/windows/win32/winstation/d...
And 50% of the times, the background fails to load and I have to double check. At first I thought it may be my specfic hardware combo but no.
What makes you think that it's "so damn hackable"?
Also, this particular attack requires administrator privileges and bypasses a security boundary that doesn't even exist on e.g. Linux. Linux doesn't have driver signatures and root can easily install a new kernel module.
> Linux doesn't have driver signatures and root can easily install a new kernel module.
Linux supports signed kernel modules (and not just on paper, this is a widely deployed feature).
Linux also has SELinux, root can't do everything there.
Yep, when booting with secure boot the kernel won't load any unsigned drivers.
This claim still assumes there's no vulnerabilities in a TCB sized in the millions of LoCs.
No chance.
Look elsewhere for actual security.
Right now, elsewhere just happens to be seL4. Anything else is either still too green or an architectural non-starter.
Just a quick look at 2024's CVEs, 0days for Windows is a security nightmare. Not singling out Windows specifically, but they have a lot.
Browsers only just recently patched browsers being able to be served javascript that scans local devices on 10.* and 192.168.* etc hitting IoT devices with exploits and payloads, hell even hitting open listening sockets on localhost and 0.0.0.0 -- that's cross platform, how many years did that go under the radar?
And now Windows is getting 'Recall' which will monitor and scan your every PC action to remember it for you using ML; I don't see that going back at all /s
>Browsers only just recently patched browsers being able to be served javascript that scans local devices on 10.* and 192.168.* etc hitting IoT devices with exploits and payloads, hell even hitting open listening sockets on localhost and 0.0.0.0 -- that's cross platform, how many years did that go under the radar?
Ironically windows was not hit by that, but the "secure"(?) operating systems of mac and linux were.
Windows isn't especially hackable, they've been taking security seriously and doing a decent job for at least a decade, and honestly these days it's a lot better than the alternatives.
Really the issue is because it's used on something like 95% of desktops. More eyes on windows means more bugs being found.
A lot better than the alternatives in terms of security?
Even if we only consider alternatives in wide use like ChromeOS or macOS, I wouldn't in any serious way consider Windows to be more secure. More compatible yes, but not more secure.
It has a significantly better security architecture than macOS, and Linux is a mess as far as desktop use goes. Can't speak to ChromeOS but I understand that's pretty locked down, and honestly that could possibly take the lead, although I was only really thinking of Linux, Mac and Windows.
Linux definitely exists in a weird limbo. While it can be secured to an extreme degree, most people aren't using Linux that way on personal devices. Especially on a desktop. ChromeOS is quite secure since it is so locked down, but imagine getting the average Linux user to like it.
Curious as to your rationale for the security architecture of macOS being inferior. Is it because of the way the security features are implemented that you lean that way? macOS has its warts, but it also has plenty of security features I'm not aware of Windows/NT having.
> Linux definitely exists in a weird limbo. While it can be secured to an extreme degree, most people aren't using Linux that way on personal devices.v
For sure. I think my minimal Alpine desktop with well defined SELinux policies is better than Windows or macOS, but most people are using Ubuntu or similar which doesn't have anything like that (AppArmor helps somewhat), and doesn't really have any of the security innovations macOS or Windows have.
> Curious as to your rationale for the security architecture of macOS being inferior. Is it because of the way the security features are implemented that you lean that way? macOS has its warts, but it also has plenty of security features I'm not aware of Windows/NT having.
I will say I'm a little out of date on new features macOS may have introduced, but back in the day I remember them not even having a proper ASLR implementation, no form of MAC, nothing even close to things like Windows Secure Desktop[1] etc. Microsoft had a well deserved horrible reputation, but they really put in a lot of effort to turn things around, and I think they succeeded but without getting due credit from most techies. Whereas Apple it seemed like were coasting on the fact that macs were not nearly as targeted as a platform.
[1] https://learn.microsoft.com/en-us/archive/blogs/uac/user-acc...
What do you mean by hackable? I can't really see how other operating systems (say, Linux+any distro) are more secure than windows fundamentally?
IMO: The backward compatibility and lots of hands touching many moving parts.
Yep, the almost impenetrable security of the last few Xboxes shows that Microsoft does have it in them to architect a very secure platform, even against physical attacks, but they don't have the luxury of doing such a clean-slate design with Windows. They can almost never afford to break backwards compatibility and the Xbox approach of running each instance of legacy software in its own fully isolated virtual machine wouldn't really scale to a multitasking environment.
For those not keeping score, the Xbox One only recently got a very limited jailbreak a decade after release, that only works on old firmware and only allows access to the innermost level of sandboxing, with the outer system sandbox, hypervisor, bootloader and optical drive handshake remaining unbroken to this day.
The Xbox is 'secure', but against the user. There are a great many PC's out there that this model doesn't work for.
It's secure against everyone, including the user.
Windows could relax that part a bit if they wanted.
It allows it's users to actually use their computer as a computer instead of a glorified phone.
MacOS nannies you left and right, preventing you from doing things you want to do because Apple says no.
Windows historically didn't have such restrictions because it's a desktop operating system and not a gimped phone. They're slowly being added, but it takes time to overhaul an entire architecture while maintaining backwards compatibility (which MacOS also doesn't care about at all).
Linux is of course far more "hackable" but there aren't as many computer illiterates using it.
I let the illiterates use it, but if they don't need root they don't get root. Debian stable with auto-unattend.
LOL you should be upvoted as your comment perfectly captures the blind arrogance of the software industry.
When you call people computer illiterate, you are blind to the technocrat injustice imparted onto the general populace.
> The obnoxious behavior and obscure interaction that software-based products exhibit is institutionalizing what I call "software apartheid":”
> ― Alan Cooper, The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity
> “When programmers speak of "computer literacy," they are drawing red lines around ethnic groups, too, yet few have pointed this out.”
> ― Alan Cooper, The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity
You too can see the light and rise above the elitism of computer literacy. You know, there are many smart people that are too prideful to put up with what computer people demand as computer literacy. They suffer in silence, you will not have their loyalty, and they will switch to competing software the moment they are able to.
What? I never said being computer illiterate is bad. Plenty of fine people are computer illiterate. And plenty of fine people are fantastic at things I'll never be good at. That's fine.
- The EULA absolves Microsoft of any liability whatsoever. So they share in none of the risk. Imagine if physical items were like this: hit one bump and your pickup is destroyed. Scissors fall apart irreparably once they contact any material that's not paper.
- MS putting backwards compatibility (mainly done for business customers) above everything, at all costs. The peanut butter factory in Indiana that's been running WFW since '89 must never be inconvenienced, even if it means tens of thousands of people have to take their brand new computers to the shop (at their own cost!) multiple times per year because of spyware infections.
- Not valuing innovation. A culture where engineers are just a necessity to keep the money-making machine running. All the excitement was drained about the end of the '90s. They made a couple nominal hits with the Surface, Xbox, and Azure, not going to discount that.
Tens of millions LOC in legacy C++ with many many compatability layers.
It's not an error, it's by design. Only issue is these "vulnerabilities" were reserved for three letter agencies.
[flagged]
In principle, there's something about Windows object system being much a much more complex abstraction than Unix's streams.
But the reality is not that. Windows is just surrounded by layers and layers of bad code with atrocious interfaces. Any architectural weakness doesn't even register.
Hard to believe Microsoft is disagreeing when there is a demo.
In that Vimeo account there are ton of other security discoveries. Eg WhatsApp running python script. Is this real or scam?
Well the demo is showing a crossing of something that ms has defined to not be a real security boundary: "Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong isolated from the kernel boundary." [0]
Another recent case: https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
On the Linux side, SELinux which sets guardrails on the root user at the kernel level is mandatory for protecting classified information. Thus, there is most certainly a security boundary between root, let alone regular users with "admin" groups/perms, and the kernel.
How can Windows, which is used all over the government, have a policy that admin users can do whatever they want with the kernel without it being a security vulnerability?
It's not as good as SELinux but you can limit the rights of admins with group policy so that they won't be able to install random drivers in the environments you speak of that need that boundary.
On the Windows side, loading arbitrary kernel code is an annoying process that involves disabling driver validation+dev mode and one or two reboots. If all components are working well, merely being an admin does not grant you arbitrary kernel access like it does on most Linux configs. You need to pay for/steal someone else's code signing certificate or reconfigure the target to boot into a special mode (that may require a Bitlocker recovery key). Nothing a malware author can't do, but like on the macOS "verify every binary" approach, a malicious actor can be blocked with a single certificate revocation at that point, no AV necessary.
As for groups, Windows has a variety of groups with a range of permissions (both local and over network shares). On home installs, the default user will have all of the permissions, kind of like on how most Linux installs have a single sudo/wheel user. Every kernel object has a different ACL that can be altered down to the user level. Furthermore, Windows differentiates between various permission levels ("browser content rendering process" vs "normal process" vs "admin process"), doing things like preventing keystroke insertion into higher privileged processes running under the same user account.
In office/corporate environments, the person interacting with the computer never gets admin permissions at all, so the admin/kernel boundary isn't relevant until a privilege escalation exploit is involved. Even IT administrators should almost never use real admin accounts; almost everything from changing passwords to reconfiguring permissions and settings can be done with assigning users to lower privilege groups or the right ACLs, not entirely unlike how Linux capabilities can be used to grant relatively low-power users permissions that normally only root can use.
Windows's security problem isn't unlike Linux's: it can be locked down securely, but you'll break tons of applications and you'll need to read through tons of obscure documentation before you can pull it off. Out-of-the-box Windows has a lot of security features that Linux lacks, but when it comes to unmanaged home computers owned and used by normal people, neither has any real protection boundary preventing kernel access in practice.
Because their policy is to not give admin to a user if you don't want them to have control of the computer?
The concept that there is a root/superuser account that can do anything they like is quite a common one, but it is an OS design choice. Any user account is just an object in the operating system and one can as well design an OS that enforces certain rules against all user accounts, even if that means limiting superuser accounts.
Legitimate reasons I can think of would be for example to protect certain secrets even in the event of an administrator compromise (like a TPM) or just to prevent administrators from accidentally messing up their systems to an extent that they wouldn't boot. Another (more controversial) goal is to enforce DRM.
Anyways, that's exactly what Microsoft is attempting to do with Windows: the OS tries to prevent administrative accounts from interfering with the kernel/installing rootkits (for whatever reason).
Also note that it's always important in this discussion to differentiate between administrative user accounts (in the OS) and "administrators" (people) with physical/hardware access.
It's also interesting how on both Windows and Linux normal-privilege local accounts are, practically, root equivalent. In Linux, we train people to type "sudo" in front of anything system relevant. On Windows, we train users to click through UAC prompts. When was the last time sudo said "no" to somebody for a reason other than a password typo?
(UAC is marginally better than sudo: UAC is system managed UI, while sudo is just a program. An attacker can plug in a malicious shell alias for sudo and steal your password.)
IMHO, it'd be more convenient for users and more reflective of actual security posture to get rid of both sudo and UAC (in the default setup of course) and stop pretending that there's a firm security boundary between root and the primary human local user account.
I think an equivalent way to phrase this that feels very different is: "On both Windows and Linux the default installed users are, practically, root equivalent". I guess on the basis that the user performing the installation should be in control of the system (I mean, they are; they could've just not done the installation. Where are your access controls now, blank system!)
> When was the last time sudo said "no" to somebody for a reason other than a password typo?
Sudo doesn't say no to people, much like UAC doesn't say "no" to people. In both cases, people (admins) are meant to say "no" when they don't expect to be performing an administrative operation. People who are not admins and yet need to do such operations need an administrator to authorise it.
In both cases, if it's not a single-person system, whoever is setting the machine up should be setting up limited accounts for regular use.
On Linux, most modern user-facing applications are using polkit instead of sudo. You can actually just use pkexec instead of sudo in the terminal as well.
Instead of just running arbitrary commands as root, applications can use specific pre-defined actions like "org.freedesktop.udisks2.filesystem-mount". This shows a nice localized message to the end user about what the app is trying to do, so they can decide whether to allow it or not. The system administrator can also configure certain actions to not even require authentication, useful for e.g. flatpak updates, or to block certain actions altogether.
In my experience (on Gnome at least), Linux is moving towards Windows-style sudo protection. It lacks the "press ctrl+alt+delete to verify" trick.
Windows has the advantage that you don't need to script everything. You can wrap `runas`/`System.Management.Automation.PSCredential` around every other tool if you want to, you just don't need to in most cases.
On Linux, I do not install sudo, because I do not need very often to become root, and when I need that I usually want to do multiple operations.
I believe that "sudo" is useful only on multi-user computers (including company-owned and company-managed computers), where the administrator may want to give to some users the power to do only a restricted set of privileged operations.
I always use a different user account than root, mainly not for security, but to avoid any accidental mistakes, when I could delete or overwrite other files than intended.
I believe that this is a good enough reason to justify the need to type infrequently a password in order to change roles.
So the kernel is enforcing file sharing rules (mandatory locking, in effect) by scanning on open all open file handles for conflicting mandatory locks, but doesn't check for memory mappings of these files with conflicting permissions. Oops. Seems like a straightforward fix though.
It's worth noting that Linux just got rid of its last vestige of mandatory locking. Now you can write a loaded executable without getting EBUSY. Interesting how exactly the same feature on one OS can be a load bearing part of the security infrastructure and on another OS legacy crud to be deleted.
Seems like the attack is suspiciously simple: Fool the update process into installing old versions of kernel components with known vulnerabilities. I'm no expert, but surely MS has already thought about this and has a blacklist or revocation facility or whatever?
Is the root cause here an OS design issue or just a process failure where they failed to note the broken/bad hashes in the correct spot? The latter is much easier to fix, but the (slightly spun, as always) security announcement seems to claim the former.
Maybe they have to allow downgrades because enterprise users will insist on being able to downgrade if an update breaks something?
Windows automatically downgrades when an update breaks everything...
And then schedules the update again...
What is a fairly common thing to happen...
Wow! I remember the hard time we all had at [1] (doing deep packet inspection drivers for [2]). when Microsoft first required driver signing in Windows. The workflow seemed, at first glance, even tougher than getting an app approved on the Apple Store, with documentation that was far from clear. Personally, this feels like a huge setback considering the resources companies have poured into complying with Microsoft’s requirements, only to see it exploited in this way. Of course, vulnerabilities are always out there, but it would have been reassuring if someone had uncovered this one earlier. Kudos to Alon Leviev and SafeBreach for discovering it.
[1] https://www.nektra.com/
[2] https://www.verizon.com/business/en-nl/products/security/man...
it also allows tampering with Windows 11 to actually make it a better OS because it bypasses all the Microsoft lockdown bullshit, but let's focus on the rootkits instead.
I've noticed that a surprising number of people here on HN are in favour of locking down Windows and preventing any kernel access at all to Windows users. It reeks of the "think of the children" arguments.
No, as a user which has no need for kernel access I want it locked down so the real things I care about, my data, is more secure.
It's called security in depth.
As a user who does have need for kernel access, because it's my god damn system and not yours, Microsoft's or anybody else's, I don't want it locked down.
It's called security in depth. That means you don't need to prevent all kernel access for users, because there are layers of defense.
"heh, nice argument. unfortunately, in my head I have already depicted you as the seething pathetic baby bird and myself as the smug and unflappable red angry bird"
The owner of this website (www.bleepingcomputer.com) has banned your IP address (IP)
K.
edit: VPN, ssh -D to vps & socks5 localhost worked. Can't have anything anymore.
If you have a dynamic IP it was probably banned because of someone else who had it in the past.
With widespread CGNAT and the exhaustion of IPv4 addresses this will become more and more common each day...
Haunted IPs are a thing, same as the haunted domains article also on the front page right now! https://news.ycombinator.com/item?id=41951131
Headscale, the open source backend alternative to tailscale, which frontend is open source to begin with, is worth looking into.
When I have to use Windows I always assume the computer has been compromised.