[bug-serveez] Re: Bug#540657: serveez: REMOTE BUFFER OVERFLOW

[Andreas Rottmann]

forwarded 540657 address@hidden
thanks

[ To the Debian security team: I've just confirmed and have come up with
  (what I think is) a fix for the reported security issue.

  This affects serveez 0.1.5-2.1 (lenny) and 0.1.5-2 (etch). The bug is
  also present in 0.1.7 and 0.1.6, which are not packaged in Debian.

  I can provide fixed packages for lenny and etch tomorrow. ]

Andreas Rottmann <address@hidden> writes:

> lvac lvac <address@hidden> writes:
>
>> Subject: serveez: REMOTE BUFFER OVERFLOW
>> Package: serveez
>> Version: 0.1.5-2.1
>> Severity: grave
>> Justification: user security hole
>> Tags: security
>>
>> I HAVE FOUND SERIOUS SATANIC SECURITY HOLE:
>>
>> http://packetstormsecurity.nl/0908-exploits/serveez-overflow.txt
>>
> I can confirm this buffer overflow (but I'm not yet certain if it's
> really of satanic origin -- stay tuned, I've started investigating ;-).
>
OK, I think I've isolated the issue. 

It's a stack-based buffer overflow, which can be triggered by a
malformed/malicious HTTP If-Modified-Since header. While the linked code
triggering the issue "just" causes a segfault, I think remote code
execution is just a tiny step away, but note that I'm not a security
expert ;-).

I think the attached patch should provide a fix:

>From 56d47085ba63a4059a806ce1e03804203bb40309 Mon Sep 17 00:00:00 2001
From: Andreas Rottmann <address@hidden>
Date: Sat, 22 Aug 2009 21:24:38 +0200
Subject: [PATCH] Fix potential buffer overflow in http_parse_date()

---
 src/http-server/http-core.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/http-server/http-core.c b/src/http-server/http-core.c
index 7be11a5..6abb930 100644
--- a/src/http-server/http-core.c
+++ b/src/http-server/http-core.c
@@ -773,7 +773,7 @@ http_parse_date (char *date)
       break;
       /* RFC850-Date */
     default:
-      sscanf (date, "%s, %02d-%3s-%02d %02d:%02d:%02d GMT", 
+      sscanf (date, "%9s, %02d-%3s-%02d %02d:%02d:%02d GMT", 
              _wkday, &parse_time.tm_mday, _month, &parse_time.tm_year,
              &parse_time.tm_hour, &parse_time.tm_min, &parse_time.tm_sec);
 
-- 
1.6.3.3

Regards, Rotty