103881 2003-06-07 20:04 /72 rader/ Fozzy <fozzy@dmpfrance.com> Importerad: 2003-06-07 20:04 av Brevbäraren Extern mottagare: bugtraq@securityfocus.com Extern mottagare: full-disclosure@lists.netsys.com Mottagare: Bugtraq (import) <5168> Ärende: Speak Freely <=7.5 multiple remote and local vulnerabilities (the Hackademy Audit) ------------------------------------------------------------ --[ Summary ]-- Speak Freely is a free and open-sourced software used for efficient and secure (encrypted) voice communication over the Internet. It was written by John Walker, and runs on Windows and Unix. Homepage : http://www.fourmilab.ch/speakfree/ During a source code audit, the Hackademy staff has found multiple serious local and remote security holes in this software. --[ Details ]-- * At least three exploitable stack buffer overflows were found. A single UDP packet sent to either the data port(2074/udp) or the control port (2075/udp) can crash the sfspeaker program in a way suitable for running arbitrary supplied code. * Usage of temporary files is insecure, making possible for a malicious local user to overwrite with arbitrary data any file owned by the user running Speak Freely. * Speak Freely has a network feature allowing to send back the same UDP packet he received. Because the source IP of an UDP packet can be spoofed, there is a potential for relaying malicious packets into a protected network (NATed or firewalled) if a computer having access to this network is running Speak Freely. * There are also a few static buffer overflows, more difficult to exploit. --> The text attached to this advisory is taken from the file 'log.doc' in the tarball for Speak Freely 7.6-A2, which is immune to most of these issues. We also added some technical comments. Read this text for more details about the bugs we spotted and how they were adressed. --[ Impact ]-- A remote attacker, as well as a malicious local user, can execute arbitrary code on the system with the privileges of the user running Speak Freely. These are not theoretical issues : we wrote a functional PoC exploit for the ADPCM buffer overflow on Linux. --[ Vulnerable/Patched Versions ]-- Speak Freely 7.5 for Unix is vulnerable to all of these issues. Speak Freely 7.1 for Windows and Unix (and previous releases) are vulnerable to some of these issues. Speak Freely 7.6 is patched against most of these issues, and can be downloaded here : http://www.fourmilab.ch/speakfree/ --[ Greetings ]-- We'd like to thank John Walker for his commitment in taking these issues seriously and fixing them quickly. Thanks to uzy for helping with the remote tests. -- Fozzy The Hackademy School, Journal & Audit http://www.thehackademy.net/audit.php (103881) /Fozzy <fozzy@dmpfrance.com>/----(Ombruten) Bilaga (application/octet-stream) i text 103882 103882 2003-06-07 20:04 /131 rader/ Fozzy <fozzy@dmpfrance.com> Bilagans filnamn: "speakfreely_advisory_atttachement.txt" Importerad: 2003-06-07 20:04 av Brevbäraren Extern mottagare: bugtraq@securityfocus.com Extern mottagare: full-disclosure@lists.netsys.com Mottagare: Bugtraq (import) <5169> Bilaga (text/plain) till text 103881 Ärende: Bilaga (speakfreely_advisory_atttachement.txt) till: Speak Freely <=7.5 multiple remote and local vulnerabilities (the Hackademy Audit) ------------------------------------------------------------ 2003 March 2 Added additional bullet-proofing to the audio packet decompression performed by playbuffer() in speaker.c. Before entering the decompression code, a check is made for more than one supposedly mutually-exclusive compression mode being set. If that passes, for each kind of decompression, the compressed length is checked against the maximum ever expected (which is guaranteed not to overflow the decode buffer) and, where appropriate, that the compressed data is an even number of compression frames. Failing any of these tests prints a message on standard error which identifies the sending host and the nature of the error and discards the packet. This corrects the ADPCM buffer overflow exploit reported by the Hackademy Audit (http://www.thehackademy.net/audit.php). [ The buffer length is 512*2 bytes, however the received packet can be longer, and will be expanded by twice its size into the buffer by the ADPCM decompression routine ] 2003 March 3 As discovered in the Hackademy Audit, when PGP key exchange was used, speaker.c created a temporary file in /tmp which could potentially be exploited by a race condition via a symbolic link to overwrite another file or, if the user's umask() was set insecurely, be read by a third party on the local system, compromising the key. I added secure temporary file creation routines in the new file tempfile.c, based on a modified version of the code given in: http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html which adds the ability to leave the file to be unlinked later by the caller and to retrieve the full path name as generated from the environment variables TMPDIR or TMP. I modified the code which invokes PGP to exchange the session key to use this new create_tempfile_in_tempdir(), keeping the file open until it's been processed by PGP, preventing a "jump-in" race condition. Since the umask() of the file is forced to 077, the contents of the file should be secure against anybody other than the super-user. The same temporary file risk existed for the files in which face data were saved for display with the external viewer program. I modified the face display code in speaker.c to use create_tempfile_in_tempdir(), keep the face file open until the viewer terminates, then delete it. This resolves the Hackademy Audit issues of possible buffer overflow composing a face file name from a host name, and the risk of a host name resolving to a string which might permit directory traversal. As no exogenous input contributes to the face file name, these issues can be closed. Hackademy reported a potential vulnerability due to the validation of packet length versus contents being bypassed when the faceRequest bit was set in the packet header. That particular test was due to my having unwisely opted to re-use the packet payload length field for the address of the data being requested in a face image file, which means it cannot be tested against the received packet length as for other packets. Fortunately, these faceRequest packets are all precisely the same length as they bear no payload, and have a unique value in their flags (a.k.a. "compression") field. I added a test which verifies these, which should stop any attempt to spoof downstream code long before it gets there. Packets which fail this validation are reported to standard error and dropped. [ The packet length sanity check can be bypassed using a compression flag with the 0x00000001 bit set ( == faceRequest == Comp2X), but no fFaceData bit. That means the buffer_len can be fake, which allows easier exploitation of other issues. Because arbitrary length can be given, it is also possible to trigger various stack overflows (Denial of Service) and a (probably) remotely exploitable integer overflow. ] The Hackademy Audit revealed a potential buffer overflow exploit if a VAT protocol client sent a packet with a user name longer than the 256 byte stack buffer used to edit it for display when showhosts is set. I rewrote the code to truncate the user name in the packet at 255 characters if it's longer than that. The uname field in the connection is actually 4096 characters, but only a malicious client will attempt to send a VAT packet with an ID longer than 255 characters, so there's no reason to do anything beyond protecting ourselves against such an attack. Note that we don't have to worry about this kind of buffer overflow when parsing items from RTP SDES packets, as their length is constrained to 255 bytes (see copySDESitem() in rtpacket.c). Hackademy claim that the fLoopback facility (which causes Speak Freely packets to be echoed back to the sender) has the potential for abuse since UDP packets can be sent with forged source IP addresses. Well, yes...but here I'm going to quibble. First of all, the fLoopback occurs only after the packet has passed all of the aforementioned consistency checks and been deemed a valid Speak Freely packet. Given that, the only kind of sites you're likely to be able to attack with spoofed loopback packets is other Speak Freely sites, which you can attack far more efficiently by just sending the packets directly as opposed to finding a site to bounce them off with loopback. Sure, you can use this to disguise your identity, but then you might just as well forge the identity in the first place and dispense with the loopback cut-out. The Speak Freely loopback facility cannot be used as a packet multiplier for denial of service requests--it's one packet in, one packet out, so the rate at which loopback packets are sent is limited to the rate at which they can be delivered to the site reflecting them, which cannot be greater than the bandwidth between the attacker and the victim. So...unless anybody finds a flaw in this argument, or produces evidence that the fLoopback facility is, in fact, being abused, I'm going to leave it as-is for the moment. (N.b. It would not be a Big Thing if fLoopback were simply disabled. Almost nobody uses it, as it's much easier to test with the public echo servers which delay audio before sending it back. The fLoopback gimmick dates from 1991, when it was the only practical way to test performance on point to point leased line connections. The same temporary file risk discovered by Hackademy in speaker.c also existed in mike.c's code which invokes PGP to encrypt session keys for transmission to connected parties. I rewrote the code to use the new create_tempfile_in_tempdir() function in in tempfile.c and changed the logic so the newly created temporary file is not closed until PGP is finished with it. (103882) /Fozzy <fozzy@dmpfrance.com>/--------------