6 ms·

Running a server on port 80 (< 1024) doesn't require any elevated privileges on Windows?

by jevinskie 11y ago

akira2501 11y ago
Nope. Windows got sockets before it got a reasonable privilege model.
- andrewchambers 11y ago
  stopping non root users from listening on low ports probably causes more security issues than it solves, it means crappy admins and developers just gift root access to exploits.
  - ratsmack 11y ago
    But that isn't a problem with the software, it's just human laziness. I don't know of any system that prevents a person from making poor choices.
    - andrewchambers 11y ago
      I just gave you an example, if you don't force them to be root to do something, they wouldn't have bothered, preventing the poor choice.
  - simoncion 11y ago
    > ...crappy admins and developers just gift root access to exploits. Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root. > ...stopping non root users from listening on low ports probably causes more security issues than it solves... Requiring root privs to bind to low ports prevents the following attack: * Attacker knows of a way to crash $SERVICE * Attacker has a non-root shell on $MACHINE, which runs an instance of $SERVICE * Attacker crashes $SERVICE and stands up his own malicious instance The ability to prevent an attacker from turning a service crash bug + an unprivved shell into a malicious instance of that service is a good property to have. The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port. I'm not willing to give up that property in order to make an incompetent sysadmin or developer slightly less likely to run an exploit as root.
    - andrewchambers 11y ago
      > Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root. I don't think you have a firm grasp of the state of the real world.
      - simoncion 11y ago
        > I don't think you have a firm grasp of the state of the real world. I expected you to make this objection. :) I have a rather firm grasp of the current state of both development and system administration. Note carefully that I said "$CLASS shouldn't $DO_IMPORTANT_THING", rather than "$CLASS doesn't $DO_IMPORTANT_THING". It's a subtle detail that I guess you missed. ;) I also notice that you didn't address my larger, more technical point. I guess that means that you didn't find fault in it. That's good, as it's pretty universally recognized that it's a good thing when you get near-zero-cost removal of a given class of exploits.
    - useerup 11y ago
      > The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port. Ahem. That's what Windows does. The built-in firewall (on by default on all versions) will block all attempts to receive, unless a rule specifically allows it. A rule can specify that a specific account (or group) can receive on a specific port. However, it is more common to have rules authorize programs to communicate, like e.g. allowing chrome to open outgoing TCP connections, or allowing a specific service to listen on specific ports.
      - simoncion 11y ago
        > Ahem. That's what Windows does. No need to clear your throat, I'm aware of Windows Firewall. :) I've never had to do real administration of a Windows system, so I ask: Does WF allow you to restrict which programs can be bind to a given port? This [0] doesn't make it seem like it can, [1] and my gaming machine is booted into Linux for the next several hours, so I can't check for myself. :( [0] https://technet.microsoft.com/en-us/library/cc753558.aspx https://technet.microsoft.com/en-us/library/cc753558.aspx [1] Though -frankly- it's not the best intro to that UI that I've ever seen. :(
theandrewbailey 11y ago
Windows makes up it's own rules and it isn't Unix at all.
userbinator 11y ago
This exploit doesn't depend on that; 80 might as well be 8000 or 8080(common proxy port) or anything else. Observe that the proxy port can be specified: return "PROXY 127.0.0.1:80";}
- CyberShadow 11y ago
  Don't you still need to run the WPAD "server" on port 80?
  - breen-machine 11y ago
    Yup. That's why it needs to run on port 80. I don't think Windows Firewall lets you listen on *:80, but localhost:80 is just fine.
useerup 11y ago
It does. The built-in firewall will by default block any program from listening on any port, unless authorized by a rule. The article did not touch on this subject, but I believe that for this to work, the admin will have to either switch off the firewall or create a rule authorizing the program to use the port (or the port to be used by any program)
- breen-machine 11y ago
  If you watch the video for Windows 7 you see Windows Firewall tries to block it. It is blocking Potato from listening on *:80. There are no such restrictions for localhost:80. No modifications were made from default config.

Running a server on port 80 (< 1024) doesn't require any elevated privileges on Windows?

akira2501 11y ago

Nope. Windows got sockets before it got a reasonable privilege model.

andrewchambers 11y ago
stopping non root users from listening on low ports probably causes more security issues than it solves, it means crappy admins and developers just gift root access to exploits.
- ratsmack 11y ago
  But that isn't a problem with the software, it's just human laziness. I don't know of any system that prevents a person from making poor choices.
  - andrewchambers 11y ago
    I just gave you an example, if you don't force them to be root to do something, they wouldn't have bothered, preventing the poor choice.
- simoncion 11y ago
  > ...crappy admins and developers just gift root access to exploits. Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root. > ...stopping non root users from listening on low ports probably causes more security issues than it solves... Requiring root privs to bind to low ports prevents the following attack: * Attacker knows of a way to crash $SERVICE * Attacker has a non-root shell on $MACHINE, which runs an instance of $SERVICE * Attacker crashes $SERVICE and stands up his own malicious instance The ability to prevent an attacker from turning a service crash bug + an unprivved shell into a malicious instance of that service is a good property to have. The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port. I'm not willing to give up that property in order to make an incompetent sysadmin or developer slightly less likely to run an exploit as root.
  - andrewchambers 11y ago
    > Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root. I don't think you have a firm grasp of the state of the real world.
    - simoncion 11y ago
      > I don't think you have a firm grasp of the state of the real world. I expected you to make this objection. :) I have a rather firm grasp of the current state of both development and system administration. Note carefully that I said "$CLASS shouldn't $DO_IMPORTANT_THING", rather than "$CLASS doesn't $DO_IMPORTANT_THING". It's a subtle detail that I guess you missed. ;) I also notice that you didn't address my larger, more technical point. I guess that means that you didn't find fault in it. That's good, as it's pretty universally recognized that it's a good thing when you get near-zero-cost removal of a given class of exploits.
  - useerup 11y ago
    > The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port. Ahem. That's what Windows does. The built-in firewall (on by default on all versions) will block all attempts to receive, unless a rule specifically allows it. A rule can specify that a specific account (or group) can receive on a specific port. However, it is more common to have rules authorize programs to communicate, like e.g. allowing chrome to open outgoing TCP connections, or allowing a specific service to listen on specific ports.
    - simoncion 11y ago
      > Ahem. That's what Windows does. No need to clear your throat, I'm aware of Windows Firewall. :) I've never had to do real administration of a Windows system, so I ask: Does WF allow you to restrict which programs can be bind to a given port? This [0] doesn't make it seem like it can, [1] and my gaming machine is booted into Linux for the next several hours, so I can't check for myself. :( [0] https://technet.microsoft.com/en-us/library/cc753558.aspx https://technet.microsoft.com/en-us/library/cc753558.aspx [1] Though -frankly- it's not the best intro to that UI that I've ever seen. :(

theandrewbailey 11y ago

Windows makes up it's own rules and it isn't Unix at all.

userbinator 11y ago

This exploit doesn't depend on that; 80 might as well be 8000 or 8080(common proxy port) or anything else. Observe that the proxy port can be specified: return "PROXY 127.0.0.1:80";}

CyberShadow 11y ago
Don't you still need to run the WPAD "server" on port 80?
- breen-machine 11y ago
  Yup. That's why it needs to run on port 80. I don't think Windows Firewall lets you listen on *:80, but localhost:80 is just fine.

useerup 11y ago

It does. The built-in firewall will by default block any program from listening on any port, unless authorized by a rule. The article did not touch on this subject, but I believe that for this to work, the admin will have to either switch off the firewall or create a rule authorizing the program to use the port (or the port to be used by any program)

breen-machine 11y ago
If you watch the video for Windows 7 you see Windows Firewall tries to block it. It is blocking Potato from listening on *:80. There are no such restrictions for localhost:80. No modifications were made from default config.