Dominick points out that there are a number of HTTP.SYS reservations that have relatively weak ACLs. He points out that the reason for requiring reservations in the first place (and for securing them with ACLs) is to prevent malware from hiding on an existing port:
The whole reason for ACLs on listen URIs is that malware can't easily open a new listening port – or even trickier – hide behind an already opened port (at least that was my understanding).
Kenny disagrees, commenting:
I think that the main confusion here is around the purpose of http.sys reservations. Reservations are used to prevent squatting. For example, SQL doesn't want other apps, admin or otherwise, to listen on http://+:80/sql/, so they make a reservation with their creds. Reservations are not for preventing malware from listening on your machine. If you have malware on your machine it can just open a socket if it wants to receive data.
If Kenny is correct, then it would seem to me that things would work the other way around: that is, by default you'd be allowed to register with HTTP.SYS unless some other application set up a reservation on that port/prefix. But by default, HTTP.SYS is locked down (except for the holes that Dominick is discussing). Unix set a precedent with this years ago. From section 2.9 of the classic,
UNIX Network Programming:
Unix systems have the concept of a reserved port, which is any port less than 1024. These ports can only be assigned to a socket by an appropriately privileged process. All the IANA well-known ports (0-1023) are reserved ports; hence the server allocating this port (such as the FTP server) must have superuser privileges when it starts.
Requiring network services to run with high privilege turned out to be a really bad idea, but the original goal was laudable - don't let just anybody run a well-known service on a server, perhaps spoofing the real service and collecting user passwords, etc. Using URL prefix reservations neatly solves this problem, allowing the administrator to determine who should be listening on various ports, while at the same time allowing those services to run with least privilege.
Squatting on a port is one attack. But it's only one of a myriad of attacks that this reservation system prevents. I cannot imagine that squatting was the only consideration. The port sharing ability of HTTP.SYS makes it even more vulnerable to malware than simply opening a socket. If my exploit can port share with an existing, legitimate service, you might not notice it there if you're using a traditional tool such as netstat. Plus, firewalls are configured to control access to ports - sharing a legitimate port might allow my malware to communicate with the cloud.
I'm sure malware authors worldwide rejoiced when HTTP.SYS port sharing was introduced. I'd say that concerns like Dominick's are well founded.
Of course, I don't work for Microsoft, so take my opinion with a grain of salt 8-)
Posted
Apr 01 2007, 08:40 PM
by
keith-brown