[ SOURCE: http://www.secureroot.com/security/advisories/9741709012.html ] This advisory was actually written by me back in febuary this year, only to be misplaced and forgotten about until now. Some of the applications listed, most noteably baxter and the other irc clients, were patched earlier this year as a result of me informing the relevant developers. These applications were tested on the following beos releases: r4.5, r4.5-2, r5 pro. vort-fu vort@wiretapped.net ------------------- start advisory -------------------- I know that there is a very minimal base of users actually using BeOS (if any) but this is being release none the less. If anyone has detailed information on the beos stack, please contact me privately. BeOS Applications: Felix-2-3-R4 (Irc Client) Baxter (Irc Client) Bowser (Irc Client) PostMaster-1.0 (Email Client) RobinHood-1.1 (Httpd) Felix-2-3-R4 Introduction Felix is BeOS's first available irc client, and to date, one of the most popular. Felix, like many 'Internet Aware' BeOS applications, parses data containing web specific terms such as 'http' and 'www' and creates a link which opens the string in BeOS's shipped webbrowser, NetPositive. Vulnerability The parsing of url from channel / private message text does not include proper or complete bounds checking on the length of the url. Thus if the url exceeds the bound set by Felix, the variable is overflowed and Felix crashes. The url does not need to be clicked, highlighted or accessed by any special means, the problem lies in the creation of the link to NetPositive. Example http://AAAAAAAAAA ......... |_________________________| -- 500+ characters Registers segment violation occurred 41414141 read_fault eax 00000001 ebp 41414141 cs 001b edx 001a6fe0 esi 80176200 ss 0023 ecx 00000001 edi 80176200 ds 0023 ebx 800c01c8 esp fc4c176c es 0023 fs 0000 eflags 00010282 eip 41414141 trap_no 0000000e error_code 00000004 Both Baxter and Bowser IRC Clients suffer from the same type of overflow. The lengths at which they overflow may be different, but given a high enough length they can both produce unwanted events. Baxter tends to simply crash when the url string is too long, the same as Felix. Though with Bowser (which might crash at a higher length) it simply 'resets' the user's channel screen, removing anything that was previously typed in the channel or by the user. PostMaster 1.0 (only tested on the demo version of 1.0) PostMaster also creates links to web specific terms in any recieved emails and will crash once a message with a http string longer that 512 bytes is read. Depending on how and when the message is read, PostMaster will crash everytime it is loaded until the offending email is manually removed from /boot/home/mail/in/ RobinHood 1.1-httpd Introduction RobinHood is one of the best free third party http servers for BeOS, based on libHTTP, which was created by the same author. Written entirely for BeOS with no ported code, even the upgrade from 1.0 to 1.1 fails to add proper bounds checking on recieved requests. The problem may be included in libHTTP and thus in any applications that use it. I have not had the chance to view it nor know of any actual applications that do use it apart from RobinHood. Vulnerability RobinHood fails to check received requests in both RHConsole (gui management tool) and RHDaemon (the actual server). Due to this, it is possible to crash both the console and the daemon by sending a request longer than ~4080 bytes. This error is located in the following files RobinHoodx86/source/RHConsole/source/RHCWindow.cpp int RHCWindow::ConsolePrintf(const char *format, ...) and RobinHoodx86/source/RHDaemon/source/RHLogger.cpp log_printf(const char *format, ...) Example $ telnet www.server.com 80 Trying server.com... Connected to server.com. Escape character is '^]'. AAAAAAAAAAAAAAA... - 4078+ bytes Registers segment violation occurred 41414141 read_fault http thread:regs eax 00001010 ebp 41414141 cs 001b edx 00000007 esi fc2c0d9c ss 0023 ecx 00000000 edi 80017f20 ds 0023 ebx 8000c7fc esp fc2bd3f4 es 0023 fs 0000 eflags 00010246 eip 41414141 trap_no 0000000e error_code 00000004 http thread: ------------------------- end advisory --------------------------