Paul Roberts' Musings

Wednesday February 28, 2007

in.telnetd exploit propating

It looks like a worm which takes advantage of the in.telnetd vulnerability that we described in Sun Alert 102802 a little while back is now being propagated around at least some networks.

The security team has posted some further details on our blog describing how to determine if a machine is infected, along with a script that removes the footprint (as far as we are aware of it). It also disables telnet in the process, which is something that should probably be done on all Solaris 10 or Nevada hosts right now anyway (even without this new development), at least until the machine can be patched as described in the resolution section of Sun Alert 102802.

Thursday February 15, 2007

in.telnetd vulnerability: fun with zero-days

Its been an interesting few days in the vulnerability team at Sun. As most readers of this entry will likely be aware, a serious vulnerability in the in.telnetd daemon shipped with Solaris was announced publicly on Sunday, which led to a great flurry of activity to get the issue resolved.

Thanks to work of a number of dedicated engineers who were on the ball on Sunday, and who ran with this, within a few hours of it being reported, Sun had a fix reviewed and integrated into Nevada (the current Solaris development release). Alan Hargreaves then jumped on this and started the backport to Solaris 10 (older releases are unaffected), and he has given a detailed summary of his experiences on his blog (well worth a read).

When I got into work on Monday morning Alan already had IDRs (a form of interim fix packaged up into a patch) available internally and a Sun Alert draft was in progress. In addition he was getting ready to submit his RTI (request to integrate) for the patch gates, he just needed a code reviewer and our team was happy to oblige.

The next step was getting Sun's official response published, in the form of a Sun Alert and the IDRs containing the fix. It was an advantage in this case that the problem was relatively easy to understand for someone familiar with Solaris, and as a code reviewer of the backported fix, putting together the technical details of the Sun Alert was relatively straightforward. We double checked that the IDRs worked and then passed them along with the Sun Alert to the next stage of the process, waiting for them to be published.

By Tuesday evening we had official patches tested and published.

Obviously when going through any experience like this, where our team is tested and where it's working on precisely the kind of problem for which it was invented, we learn lots of things. One of the most important, and perhaps surprising, things for me was the attention that the team's blog received.

We're still finding our feet in terms of the value that the blog can add, and it is currently effectively just a mirror of the security Sun Alerts published to Sun Solve. However, what surprised me was that for many people this is the first place they look to learn about security vulnerabilities in Sun's products. Unfortunately due to a bug in the tool the notification about the telnetd Sun Alert did not hit the blog until a good few hours after it was published on Sun Solve, and this upset a few people. We have now learned that this resource is important to people and we are hoping to raise its priority within the team.

But there's a deeper lesson to learn than that. It seems that people were following the blog because they wanted up-to-the-minute information about the progress of the vulnerability and its resolution. They wanted to actually follow the story. And not just the facts of the case, but the feedback that I have seen about Alan's blog entry has shown that people are interested in the personal voice as well. Understandably SunSolve, which is a very professional site supported by a huge infrastructure, is not designed for that sort of thing. Sun as a whole has already learned this lesson with the introduction of blogs.sun.com, and now it looks like this message is starting to filter down to the security team too.

So in hindsight it seems that our team could start filling in the blanks between the movements of the big SunSolve machine with less formal communications via outlets such as our blog and the many OpenSolaris discussion lists. An example of the kinds of things we're thinking about are potentially putting up a draft of the Sun Alert onto the blog as soon as we have finished writing it, which in this case would have meant it was available a good few hours before it appeared on Sun Solve. Another request we're exploring is allowing comments on the security blog, so that it will be more of a conversation than an information drop.

This is a learning process, and we've got a long way to go. Perhaps the readers out there can help us along the way!

Monday February 05, 2007

File descriptors and setuid applications

A recent (-ish) post on BugTraq by the XFOCUS team spawned some discussion internally. Prior to publication of this issue, XFOCUS contacted us folks in the security vulnerability team for a response, which we provided.

It seems to us that this report is highlighting a general warning about a programming error which can lead to security vulnerabilities. When a Solaris process (and those within other Unix's) launches another application (e.g. via exec(2) or one of its relations) the new process image inherits the previous image's open file descriptors. In Solaris, this fact does not change when a setuid application is launched. Because a user has control of the process from which he or she launches setuid applications, that user can therefore control the file descriptors that are inherited by the setuid application. As a result, this puts a burden on the setuid program, demanding that it use its inherited file descriptors in a safe fashion so as not to allow this situation to be exploited (and this issue is mentioned in a set of secure programming guidelines distributed within Sun that is hopefully read by engineers who are creating or fixing setuid binaries).

The exploit contained within the SecurityFocus post takes the form of a setuid binary which is a manufactured example of this kind of programming error. It writes directly to file descriptor 2, assuming that it's the usual stderr, but of course this assumption is not safe, and because the calling process closes file descriptor 2 before exec-ing the setuid program, the open(2) that occurs earlier within the setuid binary will result in that file being opened as file descriptor 2, causing the setuid application to write to that file incorrectly, at the behest of the user controlled exec-ing process.

Hopefully these programming errors are not prevalent in Sun's code (but of course if there were no vulnerabilities we wouldn't need a vulnerability team), and searching for these kinds of errors is part of the general code sweeping and review processes that go on at Sun. Certainly if a specific instance of this problem is found in an app shipped by Sun, then that is an issue that Sun would work on fixing (by patching the setuid application) and publishing in the form of a Sun Alert as soon as possible (and our team always welcomes disclosure of such issues via our normal mail address), but the security vulnerability team does not currently have plans for a direct response to the general warning published by XFOCUS.