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.
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.
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.
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
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.
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.
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.
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...").
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 always 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.
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.)
> 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.
Hey i stop here, even your first comment was god-mode wrong, sometimes it's better to just write nothing then to call drivers "apps" and clearly not knowing the difference between user and kernel-mode.
Look have fun and keep telling others that macOS and Redox has drivers who are apps...clown-show starts in 3 2 1
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 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.
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.
> 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.
> 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.
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.
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.
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:
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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...").
> 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 always 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.
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.
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.
> 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.
> 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...
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.
Hey i stop here, even your first comment was god-mode wrong, sometimes it's better to just write nothing then to call drivers "apps" and clearly not knowing the difference between user and kernel-mode.
Look have fun and keep telling others that macOS and Redox has drivers who are apps...clown-show starts in 3 2 1
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.
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 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.
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.
> 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/
Check 9front and GNU/Hurd. Namespaces are good too.
> 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.
> 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.
>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?
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.
> 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.
Why are all the billionaires using iPhones if they keep getting 0-day'd?
Shouldn't billionaires know to not use iPhones?
Also, isn't it weird that trains don't disappear like boats and planes do?
Maybe trains did disappear, and they are in the ocean, and no one thought to look for them there. And we didn't notice, because they disappeared?
(This is snark, and will still go over the head of most regardless if you knew what "observational bias" was)
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.
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?
are you a troll, a traitor, or a tin-can?
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.
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.
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.
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.
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.
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.
I let the illiterates use it, but if they don't need root they don't get root. Debian stable with auto-unattend.
- 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.
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.
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...
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 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.
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.
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.
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.
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...
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...
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.
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.