Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 66543
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Security <security@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Florian Schilhabel (RETIRED) <ruth@gentoo.org>
Add CC:
CC:
URL:
Summary:
Status Whiteboard:
Keywords:
Flags: Requestee:
 
 
  ()

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 66543 depends on: Show dependency tree
Bug 66543 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2004-10-06 09:42 0000
hi again,
this one is old... ;-)

-------------------------------------------------
No System Group - Advisory #3 - 17/04/04
-------------------------------------------------
Program:  Cherokee Web Server
Homepage:  http://www.0x50.org
Vulnerable Versions: Cherokee 0.4.16 and prior
Risk: Low / Medium
Impact: Local Format String Vulnerability
-------------------------------------------------


- DESCRIPTION
-------------------------------------------------
Cherokee is a tiny, very fast, lightweight Web
server. It is implemented entirely in C, and has
no dependencies beyond a standard C library. It
is embeddable, extensible with plug-ins, and supports
on-the-fly configuration by reading files or strings.

More informations at: http://www.0x50.org


- DETAILS
-------------------------------------------------
Cherokee Web Server is affected by a format string
bug in the PRINT_ERROR() function to 66 lines of 
common.c code:

--- common.c ---
55: void 
56: PRINT_ERROR (const char *format, ...)
57: {
58:         va_list arg_list;
59:         CHEROKEE_TEMP(tmp, 2048);  
60:         
61:         va_start(arg_list, format);
62:         vsnprintf (tmp, tmp_size, format, arg_list);
63:         va_end(arg_list);
64:    
65:         fprintf (stderr, "%s", tmp);
66:         syslog (LOG_ERR, tmp); // The bug
67: }    
--- common.c ---

We can show some parts of the stack memory by using a format string loke
this:

coki@servidor:~$ cherokee -C AAAA%08x
Can't read the configuration file: 'AAAA%08x'
coki@servidor:~$ tail -n 1 /var/log/syslog
Apr 17 15:03:25 servidor cherokee: Can't read the configuration file: 'AAAA0804b780'
coki@servidor:~$ 

---eof---

btw: the syslog looks like this:
Oct  6 18:23:21 leela lt-cherokee: Can't read the configuration file: '/usr/loca
l/etc/cherokee/cherokee.conf'
Oct  6 18:23:34 leela lt-cherokee: Can't read the configuration file: '0x804b81c
 0xbffff754 0x276e6143 0x65722074 0x74206461'

uh, memory addresses...

patch is attached (from the advisory, looks good)

--- common.c ---
55: void 
56: PRINT_ERROR (const char *format, ...)
57: {
58:         va_list arg_list;
59:         CHEROKEE_TEMP(tmp, 2048);  
60:         
61:         va_start(arg_list, format);
62:         vsnprintf (tmp, tmp_size, format, arg_list);
63:         va_end(arg_list);
64:    
<<<         fprintf (stderr, "%s", tmp);
>>>         syslog (LOG_ERR, "%s", tmp); /* oki ;-) */
67: }    
--- common.c ---

i think, a version bump would be sufficient for this (0.4.17 already in portage)...
nevertheless, it affects a server package, so it needs attention...

best regards,
florian [rootshell]

------- Comment #1 From Thierry Carrez (RETIRED) 2004-10-06 10:59:34 0000 -------
x86, please mark www-servers/cherokee-0.4.17 stable.

------- Comment #2 From Olivier Crete 2004-10-06 11:30:12 0000 -------
stable on x86... 

------- Comment #3 From Thierry Carrez (RETIRED) 2004-10-07 01:50:02 0000 -------
Drafting this one

------- Comment #4 From Thierry Carrez (RETIRED) 2004-10-07 02:53:34 0000 -------
Hmm I was confused by this one, thought it was remotely exploitable.

It's just local information leak of stack addresses, right ? If I understand this correctly, it cannot be exploited by itself. Should be fixed (and has been) but not generate GLSA.

Security, please confirm.

------- Comment #5 From Dan Margolis (RETIRED) 2004-10-07 09:22:32 0000 -------
Koon, looks correct. Local memory address disclosure. Scary! 

------- Comment #6 From Kurt Lieber 2004-10-07 09:32:40 0000 -------
ok, if it's not remotely exploitable, then I don't think we need a GLSA on this
one.

------- Comment #7 From Thierry Carrez (RETIRED) 2004-10-07 09:33:53 0000 -------
Bug closing dance

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug