HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Subdomains With Hyphens

I’ve been running a lightweight web crawler for a while just to look for interesting things. Recently I’ve noticed several web sites with hyphens at the beginning or end (or both) of their subdomain names/labels. The first time I saw it, I chalked it up to a link error, but after noticing it a few times it warranted investigation.


Here’s an example with both: http://-brainfreeze-.blogspot.com/


Obviously Blogspot allows that, but I got to wondering if that’s technically legitimate, and if so, what software accepts or barfs on it? So let’s look at the mess of RFCs that I found… RFC-608, RFC-592, RFC-1033, RFC-1034, RFC-1132, RFC-1738 and RFC-1912 all throw their hands into the host/domain name cookie jar (did I miss any?).


RFC-1912, which seems to be the latest, says (emphasis mine):

Allowable characters in a label for a host name are only ASCII letters, digits, and the `-' character. Labels may not be all numbers, but may have a leading digit (e.g., 3com.com). Labels must end and begin only with a letter or digit.


So… my interpretation is that that “-brainfreeze-“ and others are in violation of this RFC. But we all know how this really works—it only matters what the browsers support—so what do they do?


Not surprisingly, IE, Firefox (Mac & Windows), Safari (Mac) and Opera (Mac) all open the web site without a problem. Safari on the iPhone, however, fails with the error “Safari can't open the page because it can't find the server.”


So that leads us outside the browser…


Some quick mail tests show Outlook, Thunderbird and Gmail all will accept them in a “To” field. Apache seems to have no issues with them, either.


Plesk, a popular web server management package, disallows them, saying the subdomain field has an “improper value.”


For programming languages, PERL’s LWP module won’t load them (“bad hostname”), and Ruby’s Hpricot library won’t either (“the scheme http does not accept registry part”).  PHP with include/require fails (“php_network_getaddresses: getaddrinfo failed: Name or service not known”). Python’s urllib2 also spits up on it (“IOError: (-2, 'Name or service not known')”).


However, these errors may not be in any particular language or program, but based on underlying name resolution issues. It’s important to note that nslookup on Windows, and nslookup/dig on OS X and CentOS 5.2 don’t have any problems with these names (on the same hosts those languages were tried on).  I’ll try to look at the resolution libraries soon for some of those and post a follow-up.

 For web sites, Archive.org's Wayback Machine gives a vague error if you try to look up our friend "-brainfreeze-" (it differs from a nonexistent host), but Google's cache of it works. Tinyurl doesn't have any issues either. 

So is this a security issue? Probably not directly—but it may be a problem using tools against names that fit this pattern. What happens if your proxy or filter fails to parse the name, what tools rely on a “broken” ping or name lookup before they do something, what tools use urllib2 or LWP under the hood, and what hostname parsing routines will simply say they are invalid and return an error? Any one of those “minor” issues could cause a compliance failure, if not a real security issue.


So to recap, what failed in testing?

-          PERL LWP

-          Ruby Hpricot

-          Python urllib2

-          PHP include/require

-          Plesk

-          Safari (iPhone)

-     The Wayback Machine


Find others? Post in the comments, and give http://–brainfreeze-.blogspot.com/ some love for being a good test site.

Labels: Firefox| IE| iPhone| Research

[snarfs coffee]... wait, What are you doing?

While reading through an article about Firefox 3 on Security Focus today I snarfed my drink when I read the following passage:

The group also rewrote the Password Manager in JavaScript from C++ to eliminate memory errors, Schroepfer said.

Digging a little deeper I find an article talking about how OS keychain tools can interact with Firefox 3's JavaScript password manager. In the comments of the article is the following tidbit:

The JS portions mostly handle DOM interaction and file IO for
signons2.txt. The two main reasons for switching to JS are simpler code
and increased security (eg, no buffer overflows possible)
. Most of the
Firefox frontend is already JS, so this isn’t exactly a radical change.
But, in any case, the actual encryption of logins continues to be done
be a C++ component (using Triple-DES).

 There are numerous things about this that concern me:

  1. JavaScript code is *not* simple. It is highly dynamic, loosely typed, with late bindings. This means short of a syntax error, all your errors are runtime errors. Not fun to debug regardless of how awesome Firebug is. In fact, we have an entire chapter in our  Ajax Security book about nuances of JavaScript (variable scoping and declaration, oddly performing functions, deadlocks/race conditions/live locks with no mutexs, etc) that make it tricky to develop JavaScript. Dumping one language for another solely to improve readability of your code is admitting you are a poor software architect and, frankly, rather of lame.

  2. Moving to JavaScript because most of Firefox/chrome is JavaScript kind of makes sense. Moving to JavaScript from C++ to "fix" buffer overflows and memory problems is a horrible reason. You are admitting you are incapable of solving a very well known problem and the only solution was to move to a language/runtime that removed the problem for you.

  3. Is this JavaScript interface accessible from plugins or other chrome controls? Please don't tell me you just increased what can be done with Cross Zone Scripting attacks.

  4. As is pointed out in the comments of the second article, programs must be very careful when freeing memory that contains passwords. In C you can blast the buffer with junk before a free(). You have to be extremely careful with passwords in memory for managed languages like C# or Java where strings are immutable. JavaScript? No control what-so-ever over how string data is stored and destroyed. Does Spidermoney or Rhino handle JavaScript strings securely? Hmmmm...

All and all, this is a scary jolt first thing in the morning.
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.