No, I think he's straight on. Secure boot stems from a broken threat model: that kernel access is extremely important.
Talk to kernel.org and linuxfoundation.org. I think they'll be sympathetic to you viewpoint that kernel security really is no big deal. Or not.
Secure boot is a way to prevent malicious code from permanently infecting a system and to prevent infection through manipulating OS files on disk. Think rootkit. With a secure boot regime in place, linuxfoundation and kernel.org could have been spared the embarrassment of being root'ed for almost a month without even noticing (and only noticing by a coincidence).
On Windows it has gotten very difficult to infect the kernel permanently, especially on 64 bit where the kernel is loaded from MS signed cabinets and all drivers must be digitally signed to be loaded. The bad guys have now resorted to a technique where they instead boot the system to a small VM which then boots Windows. When Windows is up and running the VM will then memory patch the "guest" Windows to inject malicious code again.
Secure Boot closes that vector. It may not prevent malicious code which has somehow gotten kernel access from modifying the persistent image, but it does mean that the system will refuse to boot should that happen and you'll be alerted to the fact that somethings fishy ig going on.
I know about userspace security, but the kernel already secures userspace without secure boot and proper privilege separation secures the kernel.
kernel.org, linuxfoundation.org and several other sites were root'ed. They suspected that the attackers somehow compromised the system of one of the users and used his access to the systems. However, they must have leveraged a privilege escalation vulnerability, otherwise there is no explanation for how they can go from accessing systems as users to installing rootkits.
Privilege escalation and kernel vulnerabilities happen. There is nothing wrong with security in depth.
Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.
My thoughts too. I'm sure that MS has requirements that you will have to meet for MS to allow you to sign a bootstrapper, like e.g. requiring that the user is prompted and alerted to the fact that the system is booted to an alternate OS. Otherwise (if they allowed silent boots to non-Windows OSes) they would risk a rootkit simply silently booting a Linix and then Windows within a compromised VM. However, it is hard to see how an attack using the Linux hibernation and/or kexec vectors could lead to a compromised Windows system.
Or perhaps MJG just realized that some Linux distros (Fedora, Red Hat) now claim to use secure boot to enhance system security but not all bases have been covered.
In other words, if a system was compromised, the malicious software could reboot to a kernel with a rootkit using kexec. The compromise would not survive a system reboot, but it could allow a rootkit to hide itself and maybe even simulate a software-initiated reboot to bypass secure boot and ensure that the rebooted kernel is still compromised.
It doesn't even require 150 million pages. I would think making that many mappings wouldn't be a problem.
From JavaScript?. I think that would be a problem.
Remember, this technique tries to take the randomness out of ASLR *before* executing the exploit. With code in predictable locations the attacker can design an exploit using ROP (return oriented programming). But in a 64 bit process he cannot squeeze memory using JavaScript like he can on a 32 bit system.
You can assign the same page of physical memory multiple times in virtual memory. Therefore you can easily fill the whole virtual space with a single page.
Ok. Which JavaScript function would I use to do that?
DEP+ASLR are designed to prevent an attacker to get foothold when there *is* a memory corruption bug. To execute shell code the attacker has to somehow *bypass* DEP+ASLR. To do this he has very limited tools at his disposal. JavaScript does not allow the attacker to call the OS API or otherwise request certain memory areas.
So no, I can not "easily fill the whole virtual space with a single page" because I would have to do that with JavaScript if I am to use this technique to bypass DEP+ASLR.
VirtualAlloc with MEM_RESERVE will commit address space without reserving backing store.
Right. Can you show me how to do that from JavaScript in a browser?
Because that is what this is about. JavaScript *does not* have any function or low level binding to *reserve* memory space. It only has the ability to actually *allocate* memory (MEM_COMMIT). And that will exhaust the commit limit *long* before the address space is exhausted to the point where a library load address is predictable.
Point still stands. The technique described in the article *will not* work against 64 bit processes.
Is it possible to "rewrite the instruction pointer of the processor to a known heap address where the shellcode resides quite deterministic" on, say, Firefox on Gnu/Linux [given that flash and java are disabled in the browser]?
This is an ASLR bypass technique, not an actual exploitable vulnerability by itself. The attacker still needs an exploitable memory corruotion vulnerability to start the attack. ASLR+DEP is designed to make it much harder for an attack to gain foothold in the face of such an attack.
An exploitable memory corruption bug could for instance be a buffer overflow or use-after-free bug in a jpeg or gif library. Such a bug allows a small window of opportunity for an attacker. However, with DEP he will have a hard time injecting actual executable code into the attacked process. Instead he will use a programming technique termed ROP (return oriented programming) where he will trampoline to code carefully chosen code fragments residing at known locations.
Think of a buffer overflow bug which allows the attacker to overwrite the return address of the vulnerable function. Instead of returning to the point where thebfunction was called, the instruction pointer will return to whatever the stack was overwritten with through the buffer overflow. The attacker *still* has not gained full control. But if he can overwrite with an address pointing to a piece of code which does all or part of what he needs he can use that. If it only does part of what he needs but ends with a RET, he can make sure that the stack above the original return address points to the Next piece of usable code.
This technique will Work in any process and on any operating system where the attacker is allowed relatively free access to allocate memory. Think browsers where JavaScript can be used to allocate/squeeze memory.
So yes, this is in no way Windows specific. It is interesting because at this point the Windows ASLR is pretty much state of the art. Only recently has OS X achieved randomization of the "dyld" - the OS libraries. Even a single library being loaded in a predictable location may be enough for the agtacker to squeeze through. Linux ASLR is weaker (not as random) and many Linux libraries are still loaded at perfectly predictable locations.
The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.
Every 64-bit OS I know of uses delayed allocation: when a program asks the OS for memory, the OS assigns a chunk of address space, but doesn't assign memory (physical, virtual, or otherwise) until the program actually tries to use it. It's quite possible for a program to exhaust the available address space without actually using very much memory.
True. Butbthe OS will not commit more memory than it is *actually* able to assign to the process at some point. Once you allocated the memory it is the process to use. It may not be backed by physical or virtual memory (paging file) yet, but the OS must guarantee that memory *can* be accessed once it has committed to it.
The point still stands. There's a reason the article specifically limits the PoC to 32bit processes.
The point with ASLR is for the good process to not be infiltrated by a bad one. I dont see the problem of loading a dll in a known memory location, unless you apply that to a dll of the good application, without it detecting that.
But when you arrive at that point of being able to do that, what's circumventing ASLR good for?
You are correct that ASLR it a *mitigation*; not a failsafe protection in itself. Nor is this weakness and exploitable vulnerability *in itself*. An attacker still needs an actual exploitable memory corruption bug. But when one is found, the technique referred to as ROP can be used to bypass DEP/NX protections to gain foothold. The answer to ROP (where the attacker uses fragments of executable code loaded in known locations) is ASLR. This technique squeezes memory to take the "randomization" away from ASLR.
Just another in a long list of Microsoft/Windows security fails. Big shocker.
So would you rather use an OS with much, much weaker ASLR, like Linux where large parts of the OS and libraries are just loaded at predictable locations without any memory squeezing in the first place?
BTW, this technique will not Work on 64 bit processes. On OSes with weak ASLR and predictable locations for certain modules, moving to 64bits does not help on iota.
Based on the description, so far this is only an exploit for 32-bit versions, I wonder if the size of the address space in 64-bit Windows makes it impractical?
The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.
Unfortunately many browsers still run 32bit even on 64bit systems because of plugin compatibility. Time to move to 64 bit browser processes.
Note also that this attack is only feasible against browsers. Like other ASLR bypasses it will not Work against e.g. Outlook or Word where the attacker has very limited ability to control memory allocation.
streamline.js, a JavaScript preprocessor, does almost exactly the same thing for JavaScript. So this feature isn't unique but it is splendid.
No it does not. It uses *promises* which admittedly does make async coding simpler and more robust. It compares to task based parallelism of both C# and Java (fork-join).
But you still cannot *compose* the async flow like you can in C#. The promise is a closure which can access local/captured variables, but what it *cannot* do is terminate a loop, a branch (if-then-else) or an exception handler block which was started *outside* of the promise closure. To achieve that with promises you would have to always turn the rest of the method into a promise closure and rewrite loops, branches and exception blocks into state machines.
Not saying it cannot be done, but so far not even js does not have anything akin to C# async/await.
So in other words it is a closure, something that has been around since Scheme in 1975. Again the feature is not unique in modern times C# either, Clojure (get it right?) has them, Objective-C has them (dispatch_async), etc. etc.
You are wrong again and you are embarrassing yourself.
The C# async/await feature has nothing to do with the "asynch waiting api" of Linux.
It also is not a closure. C# has had closures since version 2.0. Java still does not have closures (but it is arriving soon in an amputated state). But I digress.
With C# async/await the compiler generates a finite state machine and *uses* closures. It turns out that the code you need to write if you want to be able to branch, loop, handle exceptions over multiple asynchronous invocations is both really complicated (finite state machines) as well as very systematic. The last point can be used to make the *compiler* write the tedious boilerplate code.
Maybe you should actually try to understand the topic instead of googling a few keyword and jump the bias-driven conclusions. Just saying.
We have the @Asynchronous annotation in Java 6 that pretty much does the same thing.
No it does not do "pretty much the same thing". Not even close.
To start with, the @Asynchronous annotation is for EJB session beans only.
C# async is a generalized async capability baked into the language. C# async works with disk IO, network IO, threads or anything else that follows one of several async patterns.
The big boon with async compared to task based parallelism (on which C# async is based) comes from the capability to write the code in a pseudo-sequential form and (not least) the ability to *compose* async tasks.
Think about how you handle exceptions in a flow of, say, 3 async calls. Without language support for async you have to register callbacks or futures which will execute once the previous task completes. How would you go about defining an exception handler that covers all 3 calls? You can't; not without some serious wrangling with closures and state machines.
Now think about how you would create a loop over async task #2. You cannot span a single while loop across the task call because the task will call back to a continuation function which syntactically needs to be *outside* the loop.
Now combine the loop with the exception handler. In Java this gets so unwieldy that it is next to impossible. In C# it is trivially easy and reads like sequential code:
The exploit you posted is two years old and fixed. But I do get your point about no OS being 100% secure. But most of these Industrial automation infections are most likely due to bad security practices or outdated and unpatched Windows systems.
Exactly. This is most likely not because of the OS but because of poor security procedures at the plant. My point was exactly that this was most likely not due to the OS but rather due to lax procedures. The carbon between the keyboard and the chair is more and more becoming the weakest link.
In short the mentality is "if it ain't broke, don't fix it". And often enough, you can get away with it.
Yes, provided that you put procedures in place which compensate for the weaknesses, e.g. if a system needs to run a 10 year old XP system then *disconnect* from the network or at least *isolate* it, block the USB ports and uninstall or block any software not needed for the operation.
I had employees plugging their iPhones into the CNC PC's to charge as well as listening to Pandora through a web browser on the CNC PC using a pair of speakers they bought in.
Oh the horror! You have my sympathies!
I now have each computer on a domain account that is locked down (no web browser), no physical USB access by the operator and the CNC PC's on their own isolated network that is filtered by a firewall (pfSense). Its far from perfectly secure but it will stop 90+% of the silly nonsense that can screw you over.
That's just silly, since the fix can be easily applied. It really nothing compared to all the wordpress exploits out the that never get patched.
Really?
This is a system that controls access to virtually all of the government public sites. It deals with extremely sensitive data and I guarantee you that no single administrator is allowed to download a patch and just apply it.
It is not a hobbyist blogging site, it is a vital piece of a country infrastructure.
Any change will have to be reviewed, tested and verified, with full sign off, logging, documentation and procedural oversight. The SOP when integrity cannot be guaranteed *should* be to shut down until reliable assessment can be made.
But, in practice, most users on a typical Windows system are basically administrators (=root, or close enough - there's always TrustedInstaller etc), and so when UAC produces a token with their original privileges restored, the net effect is the same as sudo. So, when your average user sees a UAC prompt, the end result is the same as when he does sudo whatever.
That is correct for home- and individual users. But users in a corporate (or school) setting should *not* be allowed to elevate to full admin privileges, if at all. Users can still install per-user apps and policies can still restrict which apps can be allowed to start (based on hashes, digital signatures, vendor etc).
UAC and privilege separation are two different things. The latter has been there since NT 3.1.
Exactly. NT 3.1 was the *first* Windows NT - a clean room implementation of an operating system designed to be multi-user with networked users, hence the "wasted" (at the time) space for proper SIDs with no network ambiguity like Unix/Linux.
The former is basically dumbed-down (so you don't have to type in password every time) equivalent of [gk]sudo, which is also "tagged on" on top of the normal Unix mechanism to run something under a different user account.
No, that description fits the UAC prompt. Many people assume that because the UAC prompt looks like sudo then UAC it is implemented much the same way and/or serves the same purpose as sudo.
sudo is an elevation of the user to root. sudo itself is a SUID and sets the user to run as root as the effective user. While running as root the process can do *anything* and *everything* on the system. A far cry from the least privilege security principle. But such is the Unix/Linux security model: A uid of zero means unrestricted access. A non-zero uid means there's a lot you cannot do, intrinsically. Because there are legitimate actions regular users need to do, but which is restricted in the OS because of the rather coarse grained security model (one all-powerful and the rest), SUID was invented.
UAC is a model where processes are assigned integrity levels in addition to the permissions already in the process token. The integrity model means no-write-up, i.e. a process running at a lower integrity level *can not* write or manipulate objects at higher levels. Regular desktop applications run at "normal" integrity level.
Internet facing applications (IE, Chrome, Outlook, Word/Excel/PowerPoint in "viewing" mode etc) run at "low" integrity mode. The security token and the access control checks already built into the system ensures that a low integrity process cannot write files, registry keys or otherwise make changes to the system unless the resource being written to is also "low integrity". This way the IE and Chrome can cache web pages in a special low integrity cache area, save cookies etc.
While both sudo and UAC prompt can be seen as ways to "elevate" the process permissions by changing the security "token", the reality is that Unix/Linux do not really have tokens - they have user IDs. A Unix/Linux process cannot have fine grained or specifically tailored permissions - it can only have the permissions of a user in the system - because user IDs is the way permissions are described.
Windows process tokens are initially cloned from the user who started the process (but the process inherits the integrity level from the executable and runs with low integrity level if the executable was low integrity), but the process token can be tailored, e.g. permissions removed. The Windows tokens consists of SIDs rather than a single user ID. SIDs can refer to integrity levels or groups or alternate identities.
When a user logs on to Windows, a token with all of the users permissions is initially created. But during the logon process a second token is created, one with all of the administrative privileges stripped away. This token becomes the user token and the one inherited by processes started by the user. The UAC prompt temporarily restores the original non-stripped token, allowing the user to exercise his admin rights. But crucially it does not allow him more rights than initially granted.
Compare that to Linux/Unix where the sudo "elevation" allows the process *root* permissions. Yes - sudo has been designed such that it is limits what the user can do while running - but the process as such has universal powerful privileges and a single bug can allow total system compromise. This is by no means theoretical - multiple security problems have plagued sudo and other SUIDs. It is simply not least-privilege.
My information: from using a netbook with a stock Win7 Starter installation (installed by the shop). Never asked me for setting up a user account; never asked me for a password.
Windows Starter assumes - in line with other OSes like Ubuntu or OS X - that the first user is also the administrator. You can easily set up more users - and they will default to be regular users. But even if you never create another account, you do not run as administrator by default. The UAC prompt is the way you are asked whether you are ok with your administrative privileges being invoked for the action you are trying to perform. MS reasoned that requiring you to enter your password once again would offer little extra protection: If you have decided to go ahead and ignore the screen dimming down and a warning prompt you would probably also just type in the password as well.
Never asked me for setting up a user account
And you never looked for it.
never asked me for a password.
It asks for your password each time you log on. A password is used to prove identity. You prove your identity when you log on.
And yes, I'm pretty ignorant on Windows. I'm a plain user. I got the system, I use it, that's it.
You forget about the part where you use it to post about "the real problem" on slashdot where you claim Windows mix users and system files. As if you know what the real problem is.
If I'm running as "administrator" by default, that's Windows fault to allow that to begin with and not asking me to set up a user.
But you are not running as administrator by default. Your account has the permissions to act as an administrator (as the owner of the device), but by default you are running as a non-admin user (admin privileges stripped away at logon). Would you rather that the shop retained the administrative rights and only set you up with regular users privileges?
It's my experience as a user - who hasn't used Windows in a really really long time.
I have installed drivers on the system (for my printer and "USB mass storage" drivers for my phone), without the need for a password, just clicking "allow" when the prompt came.
Yes, the system does not allow new drivers to be installed without an administrators permission. That's the prompt. Do you sincerely believe it would be more secure if you were required to enter your password once again? Didn't you decide that it was ok to install the drivers? Wouldn't you have entered the password? If you believe it should prompt for your password then by all means go ahead and crank UAC up to maximum security. Then it will ask for password. Whether a password prompt would stop stupid users from hurting themselves is a matter of debate. Personally I don't believe it will stop users who just want to install a new pr0n codec. The major barrier is that the system *does not* allow silent installs. It *will* prompt you.
Oh sorry, not even that, it was just done by the system for the USB drivers, I plugged it in and it started to do stuff. I wouldn't know whether they are "kernel mode" drivers or otherwise, nor would I truly care - it just has to work.
Yes, if the drivers are bundled with the OS or available on WindowsUpdate it will just install them, as they have been vetted and are known not to be malicious. But again, if you want to be prompted just crank up the security. For the majority of users (especially the ignorant ones) the defaults just work. Like it did for you.
Windows' mess of not keeping system files and user files strictly separate is partly to blame.
Baloney. Windows keeps operating system files separate from installed application files and separate from user content files. Really.
Even in Win7 you all the time get warnings like "this program wants to make changes to your hard disk, allow/deny?"
No you don't. You get a prompt when a program wants to make changes to the system - not the hard disk. Where do you get your faulty information? Are you making it up? Windows is locked down so that regular users cannot make changes to the operating system or installed applications. Administrators can make changes to installed application files (directories below "program files"), but *no* user run as administrator by default even if they have administrator rights.
All users' tokens are stripped of administrator privileges at logon, even if they have been granted those privileges. Windows will hold on to the original (non-stripped) token. When an application tries to make changes to protected parts of the system, the OS will determine whether the users saved token has the needed privileges. If so, UAC will prompt the user for confirmation to temporarily elevate to the saved token. If the user does not have permissions, even in the non-stripped token, the user is prompted for an account + password.
All you have to do is click "allow" and the program runs.
You obviously run with an administrator account. Which is not best practice. If you were running with a non-admin account you would be prompted for an account and a password. The account would need to have the correct permissions.
What it is changing, I don't know.
Your only correct statement so far.
It appears to give unfettered access to system files - which is totally unnecessary, unless you're running an installer.
No it doesn't. On Windows (and unlike Unix/Linux) not even the administrator have permission to change system files. Administrators do not have permission to change system files - only the special account TrustedInstaller does. And TrustedInstaller cannot log in, not interactively and not from the network.
While having access to user files only can still give very nasty results (deleting important stuff, for example), trojans have a much harder time to get to a higher level, and to hide themselves while running. Cleaning up is a lot easier, too.
And if you stopped running with an administrator account you would have realized that under Windows a user can only change his/her own files. But leaving your ignorance aside, Windows has much better protection of the system, compared to Unix/Linux and OS X:
Even administrators do not have permission to change OS files (system files). Only Trusted Installer have those permissions, and trusted installer can not log in. Only windows update and certain digitally signed installers (OS updates) are allowed to run as TrustedInstaller.
You could try to use admin privileges to take ownership of system files and then grant yourself access. That's certainly possible if your admin account holds the "take ownership" privilege. But then Windows Resource Protection kicks in. Upon reboot (before loading the compromised file) it will determine that system files have been tampered with and will restore them from an encrypted cache.
Kernel mode drivers must be digitally signed. A virus/trojan cannot inject itself into or piggyback on drivers. That would invalidate the signature and Windows will refuse to load the driver.
Windows checksums important internal tables. Even if virus/trojan should succeed in gaining kernel space access, attempts to modify tables will be discovered and the system will protect itself by restarting.
Part of the problem is design. It still harbors the design of a single user, single tasking OS which was added upon for more than a decade of incremental changes, patches and fearure improvements, one after the other after the other. It's amazing it's not messier than it already is.
[citation needed]. Where do you see a design of single user/single tasking OS?
Microsoft didn't have a plan in mind for Windows when it created DOS. It didn't even have Windows95 in mind when it created Windows 3. It's all a pile on top of a pile on top of a pile.
That may be so. But current Windows is not built upon any of those. The current strain of Windows is built upon Windows NT, which *was* a clean-room implementation of Windows. It has *nothing* to do with DOS, Windows 3 or Windows 9x/ME, except that it has a compatibility subsystem for running legacy applications.
Windows NT was always a multi-user and network-aware OS. From the very start. Unlike Unix and Linux which were designed multi-user but *not* network aware. Windows users (SIDs) are unambiguous across a network. On Unix/Linux you need to resort to all kinds of hacks, translations and reservations to make uids and gids work consistently on networked file systems.
Slashdot Mirror
No, I think he's straight on. Secure boot stems from a broken threat model: that kernel access is extremely important.
Talk to kernel.org and linuxfoundation.org. I think they'll be sympathetic to you viewpoint that kernel security really is no big deal. Or not.
Secure boot is a way to prevent malicious code from permanently infecting a system and to prevent infection through manipulating OS files on disk. Think rootkit. With a secure boot regime in place, linuxfoundation and kernel.org could have been spared the embarrassment of being root'ed for almost a month without even noticing (and only noticing by a coincidence).
On Windows it has gotten very difficult to infect the kernel permanently, especially on 64 bit where the kernel is loaded from MS signed cabinets and all drivers must be digitally signed to be loaded. The bad guys have now resorted to a technique where they instead boot the system to a small VM which then boots Windows. When Windows is up and running the VM will then memory patch the "guest" Windows to inject malicious code again.
Secure Boot closes that vector. It may not prevent malicious code which has somehow gotten kernel access from modifying the persistent image, but it does mean that the system will refuse to boot should that happen and you'll be alerted to the fact that somethings fishy ig going on.
I know about userspace security, but the kernel already secures userspace without secure boot and proper privilege separation secures the kernel.
kernel.org, linuxfoundation.org and several other sites were root'ed. They suspected that the attackers somehow compromised the system of one of the users and used his access to the systems. However, they must have leveraged a privilege escalation vulnerability, otherwise there is no explanation for how they can go from accessing systems as users to installing rootkits.
Privilege escalation and kernel vulnerabilities happen. There is nothing wrong with security in depth.
Unless you passed the entire memory image trough the TPM, how are you going to accomplish this without compromising the key to the operating system?
Let's see. How about computing a hash of the memory and pass that through the TPM?
I mean, like it is *always* done when digitally signing something.
Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.
My thoughts too. I'm sure that MS has requirements that you will have to meet for MS to allow you to sign a bootstrapper, like e.g. requiring that the user is prompted and alerted to the fact that the system is booted to an alternate OS. Otherwise (if they allowed silent boots to non-Windows OSes) they would risk a rootkit simply silently booting a Linix and then Windows within a compromised VM. However, it is hard to see how an attack using the Linux hibernation and/or kexec vectors could lead to a compromised Windows system.
Or perhaps MJG just realized that some Linux distros (Fedora, Red Hat) now claim to use secure boot to enhance system security but not all bases have been covered.
In other words, if a system was compromised, the malicious software could reboot to a kernel with a rootkit using kexec. The compromise would not survive a system reboot, but it could allow a rootkit to hide itself and maybe even simulate a software-initiated reboot to bypass secure boot and ensure that the rebooted kernel is still compromised.
It doesn't even require 150 million pages. I would think making that many mappings wouldn't be a problem.
From JavaScript?. I think that would be a problem.
Remember, this technique tries to take the randomness out of ASLR *before* executing the exploit. With code in predictable locations the attacker can design an exploit using ROP (return oriented programming). But in a 64 bit process he cannot squeeze memory using JavaScript like he can on a 32 bit system.
You can assign the same page of physical memory multiple times in virtual memory.
Therefore you can easily fill the whole virtual space with a single page.
Ok. Which JavaScript function would I use to do that?
DEP+ASLR are designed to prevent an attacker to get foothold when there *is* a memory corruption bug. To execute shell code the attacker has to somehow *bypass* DEP+ASLR. To do this he has very limited tools at his disposal. JavaScript does not allow the attacker to call the OS API or otherwise request certain memory areas.
So no, I can not "easily fill the whole virtual space with a single page" because I would have to do that with JavaScript if I am to use this technique to bypass DEP+ASLR.
VirtualAlloc with MEM_RESERVE will commit address space without reserving backing store.
Right. Can you show me how to do that from JavaScript in a browser?
Because that is what this is about. JavaScript *does not* have any function or low level binding to *reserve* memory space. It only has the ability to actually *allocate* memory (MEM_COMMIT). And that will exhaust the commit limit *long* before the address space is exhausted to the point where a library load address is predictable.
Point still stands. The technique described in the article *will not* work against 64 bit processes.
Is it possible to "rewrite the instruction pointer of the processor to a known heap address
where the shellcode resides quite deterministic" on, say, Firefox on Gnu/Linux [given that flash and java are disabled in the browser]?
This is an ASLR bypass technique, not an actual exploitable vulnerability by itself. The attacker still needs an exploitable memory corruotion vulnerability to start the attack. ASLR+DEP is designed to make it much harder for an attack to gain foothold in the face of such an attack.
An exploitable memory corruption bug could for instance be a buffer overflow or use-after-free bug in a jpeg or gif library. Such a bug allows a small window of opportunity for an attacker. However, with DEP he will have a hard time injecting actual executable code into the attacked process. Instead he will use a programming technique termed ROP (return oriented programming) where he will trampoline to code carefully chosen code fragments residing at known locations.
Think of a buffer overflow bug which allows the attacker to overwrite the return address of the vulnerable function. Instead of returning to the point where thebfunction was called, the instruction pointer will return to whatever the stack was overwritten with through the buffer overflow. The attacker *still* has not gained full control. But if he can overwrite with an address pointing to a piece of code which does all or part of what he needs he can use that. If it only does part of what he needs but ends with a RET, he can make sure that the stack above the original return address points to the Next piece of usable code.
This technique will Work in any process and on any operating system where the attacker is allowed relatively free access to allocate memory. Think browsers where JavaScript can be used to allocate/squeeze memory.
So yes, this is in no way Windows specific. It is interesting because at this point the Windows ASLR is pretty much state of the art. Only recently has OS X achieved randomization of the "dyld" - the OS libraries. Even a single library being loaded in a predictable location may be enough for the agtacker to squeeze through. Linux ASLR is weaker (not as random) and many Linux libraries are still loaded at perfectly predictable locations.
Every 64-bit OS I know of uses delayed allocation: when a program asks the OS for memory, the OS assigns a chunk of address space, but doesn't assign memory (physical, virtual, or otherwise) until the program actually tries to use it. It's quite possible for a program to exhaust the available address space without actually using very much memory.
True. Butbthe OS will not commit more memory than it is *actually* able to assign to the process at some point. Once you allocated the memory it is the process to use. It may not be backed by physical or virtual memory (paging file) yet, but the OS must guarantee that memory *can* be accessed once it has committed to it.
The point still stands. There's a reason the article specifically limits the PoC to 32bit processes.
The point with ASLR is for the good process to not be infiltrated by a bad one. I dont see the problem of loading a dll in a known memory location, unless you apply that to a dll of the good application, without it detecting that.
But when you arrive at that point of being able to do that, what's circumventing ASLR good for?
You are correct that ASLR it a *mitigation*; not a failsafe protection in itself. Nor is this weakness and exploitable vulnerability *in itself*. An attacker still needs an actual exploitable memory corruption bug. But when one is found, the technique referred to as ROP can be used to bypass DEP/NX protections to gain foothold. The answer to ROP (where the attacker uses fragments of executable code loaded in known locations) is ASLR. This technique squeezes memory to take the "randomization" away from ASLR.
Just another in a long list of Microsoft/Windows security fails. Big shocker.
So would you rather use an OS with much, much weaker ASLR, like Linux where large parts of the OS and libraries are just loaded at predictable locations without any memory squeezing in the first place?
BTW, this technique will not Work on 64 bit processes. On OSes with weak ASLR and predictable locations for certain modules, moving to 64bits does not help on iota.
Based on the description, so far this is only an exploit for 32-bit versions, I wonder if the size of the address space in 64-bit Windows makes it impractical?
yes
The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.
Unfortunately many browsers still run 32bit even on 64bit systems because of plugin compatibility. Time to move to 64 bit browser processes.
Note also that this attack is only feasible against browsers. Like other ASLR bypasses it will not Work against e.g. Outlook or Word where the attacker has very limited ability to control memory allocation.
streamline.js, a JavaScript preprocessor, does almost exactly the same thing for JavaScript. So this feature isn't unique but it is splendid.
No it does not. It uses *promises* which admittedly does make async coding simpler and more robust. It compares to task based parallelism of both C# and Java (fork-join).
But you still cannot *compose* the async flow like you can in C#. The promise is a closure which can access local/captured variables, but what it *cannot* do is terminate a loop, a branch (if-then-else) or an exception handler block which was started *outside* of the promise closure. To achieve that with promises you would have to always turn the rest of the method into a promise closure and rewrite loops, branches and exception blocks into state machines.
Not saying it cannot be done, but so far not even js does not have anything akin to C# async/await.
So in other words it is a closure, something that has been around since Scheme in 1975. Again the feature is not unique in modern times C# either, Clojure (get it right?) has them, Objective-C has them (dispatch_async), etc. etc.
You are wrong again and you are embarrassing yourself.
The C# async/await feature has nothing to do with the "asynch waiting api" of Linux.
It also is not a closure. C# has had closures since version 2.0. Java still does not have closures (but it is arriving soon in an amputated state). But I digress.
With C# async/await the compiler generates a finite state machine and *uses* closures. It turns out that the code you need to write if you want to be able to branch, loop, handle exceptions over multiple asynchronous invocations is both really complicated (finite state machines) as well as very systematic. The last point can be used to make the *compiler* write the tedious boilerplate code.
Maybe you should actually try to understand the topic instead of googling a few keyword and jump the bias-driven conclusions. Just saying.
We have the @Asynchronous annotation in Java 6 that pretty much does the same thing.
No it does not do "pretty much the same thing". Not even close.
To start with, the @Asynchronous annotation is for EJB session beans only.
C# async is a generalized async capability baked into the language. C# async works with disk IO, network IO, threads or anything else that follows one of several async patterns.
The big boon with async compared to task based parallelism (on which C# async is based) comes from the capability to write the code in a pseudo-sequential form and (not least) the ability to *compose* async tasks.
Think about how you handle exceptions in a flow of, say, 3 async calls. Without language support for async you have to register callbacks or futures which will execute once the previous task completes. How would you go about defining an exception handler that covers all 3 calls? You can't; not without some serious wrangling with closures and state machines.
Now think about how you would create a loop over async task #2. You cannot span a single while loop across the task call because the task will call back to a continuation function which syntactically needs to be *outside* the loop.
Now combine the loop with the exception handler. In Java this gets so unwieldy that it is next to impossible. In C# it is trivially easy and reads like sequential code:
try{
var res1 = await FirstAsync();
while(someCondition) {
await SecondAsync(res1);
}
var res3 = await ThirdAsync(res1)
} catch (SomeException ex) {
}
GP is correct, the async continuations is C# are pretty unique at this point.
The exploit you posted is two years old and fixed. But I do get your point about no OS being 100% secure. But most of these Industrial automation infections are most likely due to bad security practices or outdated and unpatched Windows systems.
Exactly. This is most likely not because of the OS but because of poor security procedures at the plant. My point was exactly that this was most likely not due to the OS but rather due to lax procedures. The carbon between the keyboard and the chair is more and more becoming the weakest link.
In short the mentality is "if it ain't broke, don't fix it". And often enough, you can get away with it.
Yes, provided that you put procedures in place which compensate for the weaknesses, e.g. if a system needs to run a 10 year old XP system then *disconnect* from the network or at least *isolate* it, block the USB ports and uninstall or block any software not needed for the operation.
I had employees plugging their iPhones into the CNC PC's to charge as well as listening to Pandora through a web browser on the CNC PC using a pair of speakers they bought in.
Oh the horror! You have my sympathies!
I now have each computer on a domain account that is locked down (no web browser), no physical USB access by the operator and the CNC PC's on their own isolated network that is filtered by a firewall (pfSense). Its far from perfectly secure but it will stop 90+% of the silly nonsense that can screw you over.
That's the way to do it. Props!
http://www.techrepublic.com/blog/datacenter/disable-removable-media-through-windows-server-2008s-group-policy-configuration/452
Really easy and simple. No need to script anything or to remove files from local systems.
How would you do that in Linux (which has had *many* vulnerabilities in USB drivers in *kernel* space)
the solution is to not use vulnerable crap like windows for
Right. So there would never be any risk when using Linux?
http://www.h-online.com/open/news/item/USB-driver-bug-exposed-as-Linux-plug-pwn-1203617.html
http://news.softpedia.com/news/Researcher-Demonstrates-USB-Autorun-Attack-on-Linux-183611.shtml
http://linux.slashdot.org/story/11/02/07/1742246/usb-autorun-attacks-against-linux
http://www.omgubuntu.co.uk/2011/02/how-usb-autorun-malware-could-easily-infect-linux
You are stupid to think that any OS is free of such problems. Or you are just blind to facts because of Linux fanaticism.
That's just silly, since the fix can be easily applied. It really nothing compared to all the wordpress exploits out the that never get patched.
Really?
This is a system that controls access to virtually all of the government public sites. It deals with extremely sensitive data and I guarantee you that no single administrator is allowed to download a patch and just apply it.
It is not a hobbyist blogging site, it is a vital piece of a country infrastructure.
Any change will have to be reviewed, tested and verified, with full sign off, logging, documentation and procedural oversight. The SOP when integrity cannot be guaranteed *should* be to shut down until reliable assessment can be made.
But, in practice, most users on a typical Windows system are basically administrators (=root, or close enough - there's always TrustedInstaller etc), and so when UAC produces a token with their original privileges restored, the net effect is the same as sudo. So, when your average user sees a UAC prompt, the end result is the same as when he does sudo whatever.
That is correct for home- and individual users. But users in a corporate (or school) setting should *not* be allowed to elevate to full admin privileges, if at all. Users can still install per-user apps and policies can still restrict which apps can be allowed to start (based on hashes, digital signatures, vendor etc).
..., but even a volunteer Linux admin *definitely* would have, because the virus simply wouldn't have worked.
So what types of admins were administering the server when this happened? (broke into and compromised multiple servers and sites)
Or when this happened? (Gained root access and deployed Trojans)
I guess those sites were being run by incompetent people? How else could a compromised user account lead to root access and rootkits installed?
UAC and privilege separation are two different things. The latter has been there since NT 3.1.
Exactly. NT 3.1 was the *first* Windows NT - a clean room implementation of an operating system designed to be multi-user with networked users, hence the "wasted" (at the time) space for proper SIDs with no network ambiguity like Unix/Linux.
The former is basically dumbed-down (so you don't have to type in password every time) equivalent of [gk]sudo, which is also "tagged on" on top of the normal Unix mechanism to run something under a different user account.
No, that description fits the UAC prompt. Many people assume that because the UAC prompt looks like sudo then UAC it is implemented much the same way and/or serves the same purpose as sudo.
sudo is an elevation of the user to root. sudo itself is a SUID and sets the user to run as root as the effective user. While running as root the process can do *anything* and *everything* on the system. A far cry from the least privilege security principle. But such is the Unix/Linux security model: A uid of zero means unrestricted access. A non-zero uid means there's a lot you cannot do, intrinsically. Because there are legitimate actions regular users need to do, but which is restricted in the OS because of the rather coarse grained security model (one all-powerful and the rest), SUID was invented.
UAC is a model where processes are assigned integrity levels in addition to the permissions already in the process token. The integrity model means no-write-up, i.e. a process running at a lower integrity level *can not* write or manipulate objects at higher levels. Regular desktop applications run at "normal" integrity level.
Internet facing applications (IE, Chrome, Outlook, Word/Excel/PowerPoint in "viewing" mode etc) run at "low" integrity mode. The security token and the access control checks already built into the system ensures that a low integrity process cannot write files, registry keys or otherwise make changes to the system unless the resource being written to is also "low integrity". This way the IE and Chrome can cache web pages in a special low integrity cache area, save cookies etc.
While both sudo and UAC prompt can be seen as ways to "elevate" the process permissions by changing the security "token", the reality is that Unix/Linux do not really have tokens - they have user IDs. A Unix/Linux process cannot have fine grained or specifically tailored permissions - it can only have the permissions of a user in the system - because user IDs is the way permissions are described.
Windows process tokens are initially cloned from the user who started the process (but the process inherits the integrity level from the executable and runs with low integrity level if the executable was low integrity), but the process token can be tailored, e.g. permissions removed. The Windows tokens consists of SIDs rather than a single user ID. SIDs can refer to integrity levels or groups or alternate identities.
When a user logs on to Windows, a token with all of the users permissions is initially created. But during the logon process a second token is created, one with all of the administrative privileges stripped away. This token becomes the user token and the one inherited by processes started by the user. The UAC prompt temporarily restores the original non-stripped token, allowing the user to exercise his admin rights. But crucially it does not allow him more rights than initially granted.
Compare that to Linux/Unix where the sudo "elevation" allows the process *root* permissions. Yes - sudo has been designed such that it is limits what the user can do while running - but the process as such has universal powerful privileges and a single bug can allow total system compromise. This is by no means theoretical - multiple security problems have plagued sudo and other SUIDs. It is simply not least-privilege.
My information: from using a netbook with a stock Win7 Starter installation (installed by the shop). Never asked me for setting up a user account; never asked me for a password.
Windows Starter assumes - in line with other OSes like Ubuntu or OS X - that the first user is also the administrator. You can easily set up more users - and they will default to be regular users. But even if you never create another account, you do not run as administrator by default. The UAC prompt is the way you are asked whether you are ok with your administrative privileges being invoked for the action you are trying to perform. MS reasoned that requiring you to enter your password once again would offer little extra protection: If you have decided to go ahead and ignore the screen dimming down and a warning prompt you would probably also just type in the password as well.
Never asked me for setting up a user account
And you never looked for it.
never asked me for a password.
It asks for your password each time you log on. A password is used to prove identity. You prove your identity when you log on.
And yes, I'm pretty ignorant on Windows. I'm a plain user. I got the system, I use it, that's it.
You forget about the part where you use it to post about "the real problem" on slashdot where you claim Windows mix users and system files. As if you know what the real problem is.
If I'm running as "administrator" by default, that's Windows fault to allow that to begin with and not asking me to set up a user.
But you are not running as administrator by default. Your account has the permissions to act as an administrator (as the owner of the device), but by default you are running as a non-admin user (admin privileges stripped away at logon). Would you rather that the shop retained the administrative rights and only set you up with regular users privileges?
It's my experience as a user - who hasn't used Windows in a really really long time.
I have installed drivers on the system (for my printer and "USB mass storage" drivers for my phone), without the need for a password, just clicking "allow" when the prompt came.
Yes, the system does not allow new drivers to be installed without an administrators permission. That's the prompt. Do you sincerely believe it would be more secure if you were required to enter your password once again? Didn't you decide that it was ok to install the drivers? Wouldn't you have entered the password? If you believe it should prompt for your password then by all means go ahead and crank UAC up to maximum security. Then it will ask for password. Whether a password prompt would stop stupid users from hurting themselves is a matter of debate. Personally I don't believe it will stop users who just want to install a new pr0n codec. The major barrier is that the system *does not* allow silent installs. It *will* prompt you.
Oh sorry, not even that, it was just done by the system for the USB drivers, I plugged it in and it started to do stuff. I wouldn't know whether they are "kernel mode" drivers or otherwise, nor would I truly care - it just has to work.
Yes, if the drivers are bundled with the OS or available on WindowsUpdate it will just install them, as they have been vetted and are known not to be malicious. But again, if you want to be prompted just crank up the security. For the majority of users (especially the ignorant ones) the defaults just work. Like it did for you.
Windows' mess of not keeping system files and user files strictly separate is partly to blame.
Baloney. Windows keeps operating system files separate from installed application files and separate from user content files. Really.
Even in Win7 you all the time get warnings like "this program wants to make changes to your hard disk, allow/deny?"
No you don't. You get a prompt when a program wants to make changes to the system - not the hard disk. Where do you get your faulty information? Are you making it up? Windows is locked down so that regular users cannot make changes to the operating system or installed applications. Administrators can make changes to installed application files (directories below "program files"), but *no* user run as administrator by default even if they have administrator rights.
All users' tokens are stripped of administrator privileges at logon, even if they have been granted those privileges. Windows will hold on to the original (non-stripped) token. When an application tries to make changes to protected parts of the system, the OS will determine whether the users saved token has the needed privileges. If so, UAC will prompt the user for confirmation to temporarily elevate to the saved token. If the user does not have permissions, even in the non-stripped token, the user is prompted for an account + password.
All you have to do is click "allow" and the program runs.
You obviously run with an administrator account. Which is not best practice. If you were running with a non-admin account you would be prompted for an account and a password. The account would need to have the correct permissions.
What it is changing, I don't know.
Your only correct statement so far.
It appears to give unfettered access to system files - which is totally unnecessary, unless you're running an installer.
No it doesn't. On Windows (and unlike Unix/Linux) not even the administrator have permission to change system files. Administrators do not have permission to change system files - only the special account TrustedInstaller does. And TrustedInstaller cannot log in, not interactively and not from the network.
While having access to user files only can still give very nasty results (deleting important stuff, for example), trojans have a much harder time to get to a higher level, and to hide themselves while running. Cleaning up is a lot easier, too.
And if you stopped running with an administrator account you would have realized that under Windows a user can only change his/her own files. But leaving your ignorance aside, Windows has much better protection of the system, compared to Unix/Linux and OS X:
Part of the problem is design. It still harbors the design of a single user, single tasking OS which was added upon for more than a decade of incremental changes, patches and fearure improvements, one after the other after the other. It's amazing it's not messier than it already is.
[citation needed]. Where do you see a design of single user/single tasking OS?
Microsoft didn't have a plan in mind for Windows when it created DOS. It didn't even have Windows95 in mind when it created Windows 3. It's all a pile on top of a pile on top of a pile.
That may be so. But current Windows is not built upon any of those. The current strain of Windows is built upon Windows NT, which *was* a clean-room implementation of Windows. It has *nothing* to do with DOS, Windows 3 or Windows 9x/ME, except that it has a compatibility subsystem for running legacy applications.
Windows NT was always a multi-user and network-aware OS. From the very start. Unlike Unix and Linux which were designed multi-user but *not* network aware. Windows users (SIDs) are unambiguous across a network. On Unix/Linux you need to resort to all kinds of hacks, translations and reservations to make uids and gids work consistently on networked file systems.