IIS server admins - new security advisory
-
-
been a while since we've had a PoD attack....
and now i am glad that i'm not a sysadmin, especially for windows servers.!
-
Oh. I was wondering why my critical dependencies have been a yoyo all day
-
miscreants
Don't make them sound cute and cuddly; they're dicks, plain and simple.
If you set the range way too large, it causes the Windows kernel to crash.
That's both hilarious and a bit pathetic really; why is the system set up in such a way that a simple HTTP server can crash the kernel, of all things?
-
That's both hilarious and a bit pathetic really; why is the system set up in such a way that a simple HTTP server can crash the kernel, of all things?
And ironic. HTTP.sys was invented specifically to prevent problems like this. The dll contains the minimum code that must run in kernel mode so the rest of IIS could be moved out of the kernel. You would think that they would do range checks on all of their API parameters. On a positive note, splitting HTTP.sys out of IIS is why bugs like these are much more rare than they were in the ISS 5 days.
-
And ironic. HTTP.sys was invented specifically to prevent problems like this. The dll contains the minimum code that must run in kernel mode so the rest of IIS could be moved out of the kernel. You would think that they would do range checks on all of their API parameters. On a positive note, splitting HTTP.sys out of IIS is why bugs like these are much more rare than they were in the ISS 5 days.
Why does every other web server not need a kernel driver but IIS does?
-
oh sweet, i loved the old win 95/98 PoD!
-
Why does every other web server not need a kernel driver but IIS does?
Two reasons:
- It's a shared system component that each application doesn't have to re-implement. One some-times buggy, but quickly patched HTTP engine is better than each application having its own.
- Windows allows different URLs on the same address and port to be handled by different processes.
-
I'm pretty sure Apache et al have some form of shared library thing going on. And if Linux filesystems can run entirely in userspace, why not webservers?
-
why not webservers
Windows allows different URLs on the same address and port to be handled by different processes
If the router were userspace code, then the processes being routed to would have to make themselves available to local exploits by other userspace applications.
-
I still don't see why that has to be done in kernelspace; all of those things can be done in userspace too.
-
The "routed to" applications have no access point. They aren't listening on ports, they don't have a pipe open, nothing. Since http.sys is a kernel mode component, all it needs is an entry point address and it can do a callback. This allows you to remove all system-level security handling from your code so you don't have to worry about doing it wrong.
Userspace process activation models would either need some way to talk to the program, or the router would have to launch the program. If the router launches the program, that limits the types of things you can do.
As an example, I often add web manageability to my windows services by simply registering a URL with http.sys and loading the ASP.net runtime libraries to process requests. Bingo, instant embedded web server without the worries of doing security wrong. This wouldn't be possible if I had to have something like Apache launch my service - that would make it no longer a first-class service and I couldn't do things like timer-based processing.
-
If you're worried about a process running on your computer being able to use functionality of your web server, it's already too late.
-
Shouldnt that be, "without the worries of doing it more wrong than the current version of windows/iis did it wrong"...?
-
I'm worried about a low privilege process telling my high-privilege process to do things if it sneaks a message in the pipeline after authentication, authorization and packet well-formedness checking (which are all in the http engine).
-
Then don't give the low-privilege process write permissions on the unix socket. You don't need a kernel module that handles HTTP traffic if all you want to do is prevent a process from writing to a pseudo-file if it doesn't have permission.
-
Shouldnt that be, "without the worries of doing it more wrong than the current version of windows/iis did it wrong"...?
Nope. I know all of the services I wrote this way are currently vulnerable. However, by next week, all of the servers will have windows patches and even if no one pays any attention to my applications, they'll still end up being fixed anyways. IIS has an admirable security record since they re-architected IIS this way.
A common example of the other approach is when you install something that happens to be based on the LAMP stack. If you never consciously think about and patch that instance of the stack, you will be forever vulnerable.
-
Then don't give the low-privilege process write permissions on the unix socket.
That's the point, I don't even have to create a socket. Any high-schooler that reads MSDN can set up a listener and not make a security mistake. Regular people shouldn't be put in a position of having to think about security any more than necessary... and they shouldn't think about security any less than necessary!!!
-
Wait, all you want is a listener? That's literally one line of Go:
myListener, err := net.Listen("tcp", ":http")
-
Way to miss the point.
that would make it no longer a first-class service and I couldn't do things like timer-based processing
Also, your listener is part of the Go runtime, so it's another thing that has to be patched on that system.
Also, you can't have two processes listen on the same port that way.
-
-
If you have to individually patch every LAMP instance on a machine,
Each instance will use the same binaries; patch that one set of binaries, and all your instances are now fixed!
-
If you have to individually patch every LAMP instance on a machine
No, I have to remember that LAMP is on the machine and convince someone to patch it. There's a billion lamp installations out there that got there this way:
"Hey, we need an eCommerce website"
"Use Magento"
"OK"Now you have a patch responsibility that you didn't have before.. even if you didn't realize that the above conversation is going to result in the installation of a LAMP stack.
-
I think in @Jaime's world, you have to run a separate web server for each website, and the entire LAMP stack is statically compiled into every executable. And package managers don't exist.
-
Yes, you understand me perfectly. There's no way that I'm actually saying something rational and you're totally not getting it. Good thing you're here to remind me of that.
-
-
I think in @Jaime's world, you have to run a separate web server for each website, and the entire LAMP stack is statically compiled into every executable. And package managers don't exist.
That's some nice @blakeyratting, ben.
-
I learned from a master @blakeyrat-er.
-
Nope. I know all of the services I wrote this way are currently vulnerable.
You say nope and then repeat essentially what I said but with different terminology.... You have an odd way of disagreeing.
-
If you're installing a LAMP stack without using a package manager, then you deserve all the hellfire you get. Use a package manager though, and you're just a
sudo apt-get upgrade
from patching every instance.And INB4 "But that's not Windows Update"; who the fuck cares? Does it update stuff? Yes? Then it's the same thing.
-
PS C:\windows\system32> sudo apt-get upgrade sudo : The term 'sudo' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + sudo apt-get upgrade + ~~~~ + CategoryInfo : ObjectNotFound: (sudo:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException
-
-
Why does every other web server not need a kernel driver but IIS does?
Performance, it seems... See: In-kernel web server. FWIW, there's an in-kernel httpd for the Linux kernel (albeit not included by default there), and a few other systems have one too.
Whether or not that still makes sense, I don't know. The references regarding performance on the wikipage are from early 2000, so the issues might no longer be relevant.
-
FWIW, there's an in-kernel httpd for the Linux kernel (albeit not included by default there), and a few other systems have one too.
systemd-journal-gatewayd.service
Disabled by default, and part of FDO/GNU/Linux, not the kernel
-
systemd-journal-gatewayd.service
<small>Disabled by default, and part of FDO/GNU/Linux, not the kernel
The Linux kernels and others implement TUX http://en.wikipedia.org/wiki/TUX_web_server. I don't see the relevence in the systemd log server.
-
No, I have to remember that LAMP is on the machine and convince someone to patch it.
How is this different than remembering that you have a Windows machine running and that you need to run updates?
-
It's common to install a LAMP-based product and think of PHP as just a dependency. Windows will yell at you if you don't set up automatic updates, PHP will just sit there and get infected until you take action.
-
It's common to install a LAMP-based product and think of PHP as just a dependency. Windows will yell at you if you don't set up automatic updates, PHP will just sit there and get infected until you take action.
Sorry, still not seeing it. How will Windows yell at you? In a different way than the L part of the LAMP stack telling you that you have updates? If the server just sits out there serving stuff up and you don't do anything with it, won't they both get out of date on all sorts of stuff?
I'm not a sysadmin, but either case of missing updates seems like negligence, and I don't see how one or the other is obviously easier to do. I'm also assuming you're not just allowing your servers to update and reboot at their own whims.
-
Sorry, I meant a LAMP-based product on Windows -- so WAMP. Windows actively tells you "Hey idiot, updates aren't turned on". PHP doesn't and PHP updates don't get delivered via Windows Update.
-
Not even when installed by Web Installer?
-
Sorry, I meant a LAMP-based product on Windows -- so WAMP.
Ah, yes. Windows Updates deficiencies strike non-MS products again.
-
Not even when installed by Web Installer?
Dunno. Google gives me nothing useful when I do this: