8 ms·

Yeah it's a CYA move by MS. Same reason they don't ship a telnet client by default. Or why you have to double opt-in for gzip with ASP.NET+IIS. I'm guessing, l

Yeah it's a CYA move by MS. Same reason they don't ship a telnet client by default. Or why you have to double opt-in for gzip with ASP.NET+IIS. I'm guessing, like SELinux, what users end up doing is just disabling things completely (or enabling all options) instead of figuring out all the specifics. I understand, no one wants to be responsible for shipping a vulnerability by default, like MS products used to be. Also see their terrible HTTP.SYS reservation system. Any program can listen on a socket. But if you want to use that socket for HTTP and use the OS-provided functions? Boom, special ACLs apply; enjoy figuring out a special one off utility. Or just run your service as a local admin.

dogma1138 12y ago
Yeah it's not great, but there's a good reason why there's an ACL for HTTP.SYS name reservations, a malicious application can actually reserve system reserved names, or overwrite the names of other services which already reserved a name such as the IIS or SQL server running on the machine. It's quite an annoying thing to understand Windows permissions, especially when you are using built-in drivers and services such as HTTP.SYS. Also don't forget that when you interact with HTTP.SYS you are interacting with a kernel mode driver, sockets can be bound in user space, so you are dealing with more privileged content. P.S. Network Service can use HTTP.SYS reservations, and pretty much anything else AFAIK.
- MichaelGG 12y ago
  Right, so deny access to apps trying to listen on reserved ports/namespaces. Instead, if you use sockets, you're free to listen on, say, 6666 just fine. But asking for HTTP on the same port results in a permissions error. This is obviously dumb behavior.
  - dogma1138 12y ago
    Different scopes, HTTP.SYS actually processes and routes HTTP requests in the system, think of it as an HTTP proxy router. This is a kernel mode driver, and a misuse of it can compromise the entire system. It's not dumb behavior, but that's the "price" you have to pay when you have a system component that allows you to handle HTTP requests easily, it also removes the requirement for an HTTP server to have a working socket on the system since HTTP.SYS for example can route requests to multiple virtual servers on the same machine using the same socket based on the URI requested. And more importantly allows applications to communicate over HTTP without implementing a TCP/IP or any other networking stack, they only need to register with HTTP.SYS and it works, heck if you really want too you can instruct HTTP.SYS to strip all the HTTP protocol related stuff from the traffic and then you don't even need to implement "HTTP" in your application either. Sockets require very little permissions to bind because binding a socket cannot have adverse affects on the entire system, if it's in use by another app it wont allow you to do it.

dogma1138 12y ago

Yeah it's not great, but there's a good reason why there's an ACL for HTTP.SYS name reservations, a malicious application can actually reserve system reserved names, or overwrite the names of other services which already reserved a name such as the IIS or SQL server running on the machine. It's quite an annoying thing to understand Windows permissions, especially when you are using built-in drivers and services such as HTTP.SYS. Also don't forget that when you interact with HTTP.SYS you are interacting with a kernel mode driver, sockets can be bound in user space, so you are dealing with more privileged content. P.S. Network Service can use HTTP.SYS reservations, and pretty much anything else AFAIK.

MichaelGG 12y ago
Right, so deny access to apps trying to listen on reserved ports/namespaces. Instead, if you use sockets, you're free to listen on, say, 6666 just fine. But asking for HTTP on the same port results in a permissions error. This is obviously dumb behavior.
- dogma1138 12y ago
  Different scopes, HTTP.SYS actually processes and routes HTTP requests in the system, think of it as an HTTP proxy router. This is a kernel mode driver, and a misuse of it can compromise the entire system. It's not dumb behavior, but that's the "price" you have to pay when you have a system component that allows you to handle HTTP requests easily, it also removes the requirement for an HTTP server to have a working socket on the system since HTTP.SYS for example can route requests to multiple virtual servers on the same machine using the same socket based on the URI requested. And more importantly allows applications to communicate over HTTP without implementing a TCP/IP or any other networking stack, they only need to register with HTTP.SYS and it works, heck if you really want too you can instruct HTTP.SYS to strip all the HTTP protocol related stuff from the traffic and then you don't even need to implement "HTTP" in your application either. Sockets require very little permissions to bind because binding a socket cannot have adverse affects on the entire system, if it's in use by another app it wont allow you to do it.