A 13 year old froot

While the original AIX rlogin -froot vulnerability is celebrating its Bar-Mitzvah, a Solaris telnet vulnerability with the same exploit path surfaces.

Looking at the code almost makes you cry. It’s very likely that both the original AIX rlogin problem and this recent Solaris problem stem from the same bad AT&T UNIX code fragment.

Is it possible that nobody knew about this problem until today? I wouldn’t bet on it. (Update: After reading the explanation by Casper it seems it’s not the same bug, but a set of incredible coincidence. It also seems to be a new problem for Solaris 10 only. Good thing I didn’t really bet on it…)

Watching our customers at Beyond Security trying to deal with this issue was very educational. I can roughly stereotype them into three categories:

The first category are those that are well on top of their security problems. They do daily or weekly VA scans and are used to receiving reports that show only minor problems (what we call “low risk”). An open telnet port would be in this classification, so they usually already knew about Solaris boxes with open telnet – they can quickly go around and close them. I especially like those customers – they are proactive, and they are usually very proud of their network’s security (one of our customers says he looks forward to the periodic audits since his business unit always passed them with flying colors). It took years for those customers to reach this level, routinely running scans and fixing issues until they got to this stage – but now they are reaping the rewards, and when everyone runs around in patch Tuesday they fix the one or two problems that they need to fix. Yes, these organizations are rare – but I’m mentioning them to let you all know those unicorns exist.

The second category use our scanning box “whenever there are problems”. We usually get a call from them on an outbreak like this, asking “are you testing for this problem?” (answer: “yes, and if you’d be running scans on a daily basis like we recommend you’d already have a report about it”). They usually opt to scanning the entire network for just this problem, ignoring all others. It’s hard to blame them – lack of IT security resources, impossible operating demands, support for legacy systems all make their jobs so much harder. So those guys typically scanned their network for this specific problem, hoping there are no old, unmaintained boxes or ‘surprise’ installations nobody knows about. Would a simple nmap do the trick here? Possibly, but for many having a PDF report that can be sent to management is the key. For others, the fact you can open a trouble ticket is valuable.

This group also opts for the workarounds, like blocking the telnet port. They worked harder, but got through the day.

The third group I feel really sorry for. These guys got up in the morning and heard there is a new Solaris 0-day. How many Solaris boxes do we even have on the network?

So they login to our box and do a quick datamining to see how many Solaris boxes are on the network and where they are. But hey, there is no data for network segment XYZ! (didn’t we tell you to scan everything? Sorry, I take it back – now is not the time for an “I told you so”). So the scan data is outdated – they haven’t done a scan for over a month and god knows what changed since then. Ok, lets run a quick scan on the entire network. Results come back and the room starts spinning – customers machines running Solaris that they have no control over. Backend machines that are untouchable. Even VoIP servers running Solaris with the telnet open. Oh yeah, it’s gonna be a long night.

So you see, there’s this grasshopper, who is not preparing for winter. Oh, you got the moral of the story already? good.

  • XenoMuta

    I bet this telnet mayhem has already started a port scanning frenzy among script kiddies.