How secure is your localhost domain? Hint - it may not be what it says
According to the t-shirt 'There's no place like 127.0.0.1' but just how secure is this particular home? And should recommendations become instructions to end ambiguity?
A Google engineer, Mike West, obviously doesn't think that the 127.0.0.1 domain is secure enough. West has submitted a standards draft to the Internet Engineering Task Force (IETF) seeking to formalise treating localhost in a secure context.
In his draft, West wants to update RFC6761 so that the localhost domain and any names falling within it resolve to a loopback address. "This would allow other specifications to join regular users in drawing the common-sense conclusions that localhost means localhost" West insists "and doesn't resolve to somewhere else on the network."
A loopback address is, essentially, a self-addressed envelope that goes to the same place it was sent from. Open 127.0.0.1 in your browser client and it will request any content found being served by the same machine that requested it. Localhost is most often used when developing websites or apps, to prevent the risk of unfinished (and potentially insecure) projects being exposed to the online world at large by mistake.
Duncan McAlynn, principal engineer and security evangelist at Ivanti, told SC Media that localhost is "a lazy man's shortcut" and if left unwatched "can and will eventually lead to misuse whether by developers or malicious actors."
So what security risks are there with the current IETF standards as they apply to localhost? Paul Ducklin, senior technologist at Sophos, told SC Media that for human-friendly simplicity the internet name "localhost" means exactly the same thing as either 127.0.0.1 (on an IPv4 network) or 0.0.0...0.0.1 (on an IPv6 one)
and you're supposed to be safe using that name.
"Unfortunately, and this is the main issue covered in Mike West's proposal" Ducklin says "the relevant internet standard only actually says that localhost *should* refer to your current computer, and doesn't insist that it *must*."
It might not look like a great difference, but actually it's huge in the world of Internet standards. If it's not a 'must' then corners can be cut and often will be.
"Sloppily-written client software or sloppily-written server software could, either accidentally or by design" warns Ducklin "subvert the understood meaning of localhost and direct you to some unknown computer out there on the internet."
In other words, standards-compliant code could compromise security by leaking supposedly local data which could then be abused by a malicious actor. Ducklin compares this to insisting a user sets a password, but allowing it to be blank.
What West is suggesting, therefore, is that all the 'shoulds' are replaced with 'musts'. Thus removing any confusion, or leeway, regarding the localhost definition and making compliance checking easier.
So what should enterprise security teams be doing to minimise the security risk of localhost before any alterations to the standards are made, which wouldn't be for at least six months as IETF drafts are open for that long before any decisions are made?
"The existing internet standard for localhost already permits applications to recognise this special name, and to force it to refer to the local computer" Ducklin told SC. And does so without relying on any other software further down in the system to make that choice.
In other words, Ducklin concludes "you can already and easily make your software compliant with both the letter and the spirit of both the current standard and the proposed new one, so why not do just that?"