New Windows driver signature bypass allows kernel rootkit installs
bleepingcomputer.com
bleepingcomputer.com
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.
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''.
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.
> 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.
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.
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?
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 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.
> 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?
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.
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.
I never made any such claim.
> the fact that users and Microsoft differ on what constitutes a security boundary
I never made that claim either.
> 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.
Thank you for agreeing with the claim I actually did make.
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.
This is about drivers...
2) driver vulnerabilities are there regardless of user setup. Making a user click a UAC button doesn't make the vulnerability disappear
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.
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.
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)
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.
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.
> 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.
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.
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...
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.
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.
Can't you just install it at the user level? https://code.visualstudio.com/docs/setup/windows#_user-setup...
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?
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.
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.
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.
The recent global ClownStrike outage?
If you aren't entirely in the know crowdstrike had a very similar issue a few months before with Redhat distros so was that a Redhat issue?
If you meant "caused by", then maybe use that instead of "involving"? ;)
I'm not that worried about that, as the executable won't get admin privileges without some exploit, so I don't go there. But it's an option.
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
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
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.
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.
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 a Linux user actually has to do--and not do.
> create a second unprivileged account and log into that instead of root.
No, you create one account. The root account doesn't have to be created. It's automatically there, built into the system. On Windows, you have to explicitly create two separate accounts, one with Administrator privileges and one without.
Correct, but you're missing the point. There's practically no difference between Linux and Windows when you need to escalate privileges, except having to enter credentials for another (privileged) user than your current (unprivileged) user. The security boundary is there and the user experience is basically the same. Everything else is just nitpicking.
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.
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...
(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.
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.
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.
> 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.
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.
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.
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.
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.
I have seen them. I do not use them! I very rarely install anything from outside distro repos or language repos.
> 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.
You have missed my point. You do not have to use sudo
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".
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.
UAC is strictly better than sudo IMO.
Does UAC solve security for windows? Of course not, but we were comparing against sudo here.
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...
You’re right, fake sudo prompts is how people get exploited all day long. I’ve witnessed it on MacOS.
For UAC, the user still has to learn that the darkening on the screen and the prompt is “serious business.” I think that when a password is present and has been willfully supplied, prompting the user for the password guards against automatic/accidental acceptance (button-only user confirmation prompts). I understand that many users have a joke password that might as well not be something that’s not really any more secure than a click on a button.
I see that Sudo for Windows has been restricted to Desktop only. https://hudsonvalleyhost.com/blog/microsoft-officially-exclu...
From the design article you linked, I know it’s 2006 era:
> You hide the real mouse cursor and show a fake one some number of pixels offset to the real one
I think MacOS only in the recent years has “Full Desktop Control” as an accessibility-category permission (a confusing category to boot) it enforces on apps to prevent faking the cursor.
No - the problem here is moreso the sheer complexity of Windows and the variety of devs involved and the push for backwards compatibility.
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.
[1]: https://learn.microsoft.com/en-us/windows/win32/winstation/d...
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.
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.
Windows could relax that part a bit if they wanted.
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.
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
Ironically windows was not hit by that, but the "secure"(?) operating systems of mac and linux were.
Linux supports signed kernel modules (and not just on paper, this is a widely deployed feature).
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.
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.
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.
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.
>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.
You could configure all manner of security settings on Linux, of course, but on most Linux distros they're all left unconfigured.
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.
By comparison, 3rd party kernel modules are rare and looked down upon on Linux and outright banned on macOS.
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...
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 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"?
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 ?
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.
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.
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.)
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.
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?
Kind of. There is a set of permissions an application can request in order to access protected services and areas of the filesystem, but maybe that's what you meant with sandboxing?
https://support.apple.com/en-gb/guide/mac-help/mchl211c911f/...
That tells us some things about MacOS security, but nothing about Windows.
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.
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.
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.
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)
That was a long time ago, the 1980s and 1990s. Windows has been transformed since then, particularly with Windows 10.
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...
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.
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.
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.
- 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.
Really the issue is because it's used on something like 95% of desktops. More eyes on windows means more bugs being found.
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.
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.
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...
https://book.hacktricks.xyz/macos-hardening/macos-security-a...
ASLR on macOS has gotten a lot better, with full randomization down to the kernel since El Capitan I think. Fixed page offsets (the worst offense imo) were also removed. The secure enclave brought CMAC and PAC soon after.
> https://book.hacktricks.xyz/macos-hardening/macos-security-a...
I think there is something equivalent to that, although I don't know that it's part of a specific framework.
There are privacy protections in place for accessing various hardware and permissions needs to be granted [1]. I think the rest of what that link covers is handled by UAC.
> ASLR on macOS has gotten a lot better, with full randomization down to the kernel since El Capitan I think. Fixed page offsets (the worst offense imo) were also removed.
Nice!
I do think Apple was lagging behind but these days I suppose there would be parity for what have become basic features. I still think macOS should have some sort of MAC implementation though, but maybe they just need a little more time ;)
[1] https://support.microsoft.com/en-us/windows/windows-desktop-...
See also Raymond Chen's summary of this class of attack:
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
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.
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.
And then schedules the update again...
What is a fairly common thing to happen...
In that Vimeo account there are ton of other security discoveries. Eg WhatsApp running python script. Is this real or scam?
Another recent case: https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
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?
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.
[2] https://www.verizon.com/business/en-nl/products/security/man...
> possible by gaining kernel code execution as an administrator
> The researcher published a tool called Windows Downdate
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.
Writing '15' would have been easier here. Nothing wrong with writing 0xF but it's a weird choice that irked my curiosity. You just did it for style reasons?
Another weird choice, different syntax. I triggered a little when I saw the comment too.
0xF has always been hard to read for me. $F is hard to read for others, and it all seems to depend on where and on what we all started with.
I will start lists and notes from 0, and have dropped a few hex expressions in my time. Sometimes I am in an odd frame of mind and maybe am just signaling that to see what others may do or say.
It's called security in depth.
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.
Why do you need it?
Want to lock down Windows? You should have that power. It would be absolutely idiotic if you couldn't secure a computer. But, do you want to fuck with the kernel, patch out something you think should never be called by anything because there is no legitimate use case? You should also have that power.
Because one thing that stuff like this doesn't do is "make it easier for the bad guys": want to deliver a malicious payload by exploiting Windows, either because of its design or a recently found vector? I hope you die in a fire but you already have so many options that this one really doesn't give you more power than before. It's just another option in a litany of options. After all, Windows is only as safe as its users with admin powers, which is literally every home user thanks to elevated access being a single "ok" button, if they even have UAC still turned on "because it's so annoying".
K.
edit: VPN, ssh -D to vps & socks5 localhost worked. Can't have anything anymore.