xorl %eax, %eax

OpenBSD SMTPd Remote Crash

with 8 comments

This bug was reported in openbsd-bugs mailing list on 4 October 2009 by James Turner. His report was for OpenBSD-CURRENT release and as you can see it was easily triggered by sending an “AUTH PLAIN” request after “MAIL FROM”. Here is the code that handles this from src/usr.sbin/smtpd/smtp_session.c:

int
session_rfc4954_auth_handler(struct session *s, char *args)
{
	char	*method;
	char	*eom;

	if (! ADVERTISE_AUTH(s)) {
   ...
	if (s->s_state == S_GREETED) {
		session_respond(s, "503 Polite people say HELO first");
		return 1;
	}
   ...
	if (strcasecmp(method, "PLAIN") == 0)
		session_rfc4954_auth_plain(s, eom);
   ...
	return 1;
}

Now, if we jump to that routine we’ll see this:

void
session_rfc4954_auth_plain(struct session *s, char *arg)
{
	struct auth	*a = &s->s_auth;
	char		 buf[1024], *user, *pass;
	int		 len;

	switch (s->s_state) {
	case S_HELO:
   ...
	case S_AUTH_INIT:
   ...
	default:
		fatal("session_rfc4954_auth_plain: unknown state");
	}

abort:
	session_respond(s, "501 Syntax error");
	s->s_state = S_HELO;
}

So, it is kind of obvious that since the state isn’t S_HELO or S_AUTH_INIT, it will fall into the default case which will invoke fatal() and consequently, stop the SMTPd application. To fix this, the following patch was applied:

  
+	if (s->s_state != S_HELO) {
+		session_respond(s, "503 session already in progress");
+		return 1;
+	}
+
  	if (args == NULL) {

This was added in session_rfc4954_auth_handler() to ensure that there could not be an authentication after a session has been established. Well, in my opinion, this could be considered a security related bug since it results in a reliable SMTP remote DoS situation. However, It seems like the OpenBSD guys have different opinion and didn’t even mention that bug.

Written by xorl

October 14, 2009 at 18:39

Posted in bugs, openbsd

8 Responses

Subscribe to comments with RSS.

  1. smtpd is not even released yet. you don’t do errata for the product that’s not even finished.

    anonymous coward

    October 14, 2009 at 21:20

  2. i’m glad you could find that cras^W fatal() that’s reached for an unhandled case in an product that’s still an unreleased work in progress. good job …

    gilles

    October 21, 2009 at 08:09

  3. Wow, the code’s author must be some kind of massive lamer to let such obvious bugs go by !

    Antoine

    October 21, 2009 at 08:33

  4. @gilles: I didn’t find it. I just wrote that analysis. James Turner report it to the openbsd-bugs mailing list as I said in the post.

    xorl

    October 21, 2009 at 20:02

  5. I was only refering to your conclusion:

    “Well, in my opinion, this could be considered a security related bug since it results in a reliable SMTP remote DoS situation. However, It seems like the OpenBSD guys have different opinion and didn’t even mention that bug”.

    The “OpenBSD guys” enabled smtpd in the build so that testers, like James, could easily report bugs. There’s a reason why OpenBSD still uses and enables sendmail by default instead of smtpd, why there’s so many requests for *testers* to update their tree after some commits and why there’s so many mails from me in the archives warning people that they should not use this in production every time someone asks a question on one of the mailing lists.

    Posting a report is ok, making it sound like we’re trying to hide bugs in production ready software when its ‘work in progress’ software for which there’s been no announcement mail telling people they can start using it live is either an unfortunate mistake, or a deliberate lie. I hope it was a mistake, in which case my comments will simply serve as yet another warning for your readers NOT to use beta software live.

    gilles

    October 24, 2009 at 10:42

  6. @gilles: It was a mistake and I apologize to all readers for not knowing that it is still under testing.

    But… what about that about that recent XMM unhandled exception? [1]
    It was resulting in instant kernel panic and it was classified as a “reliability fix”. Isn’t that a security related issue? Why it doesn’t get mentioned in the security advisories’ page [2]?

    To clarify, I don’t know much about OpenBSD, I’m just a common user so I might miss something here. :)

    [1] http://openbsd.org/errata46.html#002_xmm

    [2] http://openbsd.org/security.html#46

    xorl

    October 24, 2009 at 11:29

  7. Good :-)

    I am mostly a userland/daemons guy so details behind that XMM bug I don’t know, however the classification I can explain.

    Bugs described on errata pages are classified as “security” related when they impact the integrity of a system (ie: privilege escalation, information leakage due to weak crypto, anything allowing a user to access privileges or informations which he shouldn’t be able to given his original privileges). Simple crashes/fatals/panics are classified as “reliability” related because they only affect the reliability of the system (ie: it sucks that a user can provoke a daemon to stop responding, but it does not have the same impact on the system than a user suddenly becoming root).

    After applying a “reliability” fix, you’re all set and issue is fixed. After applying a “security” fix, you may need to do a more annoying investigation to determine if binaries have not been replaced by attacker, if kernel has not been altered, if someone did not leave a backdoor, etc etc …

    The reason why they both appear on security.html is more of a convenience I guess.

    gilles

    October 26, 2009 at 12:00

  8. Thanks, nice to know.
    That reliability/security separation makes sense but it might lead to uncomfortable cases when bugs that aren’t trivially exploitable are classified as reliability bugs.
    Anyway, thanks for you reply. :)

    xorl

    October 26, 2009 at 21:36


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s