A Debian bug report [1] indicates: "My concern is the third gnutls_record_recv() call. 'maxlen' argument of TLS_readline() was passed to the call as is, and TLS_readline() callers *always pass the full size* of TLS_buffer[] as 'maxlen', but pointer passed to the gnutls_record_recv() is (TLS_buffer + some offset). So, in theory, remote side could send specifically prepared data which could overwrite up to MAXTOREAD bytes past the buffer. As I'm not a security expert, I can't say for sure if it is really exploitable or not, but it does not look good at all." To exploit, a user would need to be coerced into running echoping against a malicious HTTPS site that sends back certain crafted data. This affects version 6.0.2 as found in Fedora; upstream has committed a fix [2]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606808#22 [2] http://echoping.svn.sourceforge.net/viewvc/echoping/trunk/SRC/readline.c?r1=427&r2=430
Created echoping tracking bugs for this issue Affects: fedora-all [bug 705174]
Upstream bug report: http://sourceforge.net/p/echoping/bugs/55/ This is still unfixed in current Fedora. CVE request: http://seclists.org/oss-sec/2013/q4/120
Hi FYI: CVE-2013-4448 was rejected, and CVE-2010-5111 assigned for this issue. See: http://marc.info/?l=oss-security&m=138238646504844&w=2 Regards, Salvatore
*** Bug 1803069 has been marked as a duplicate of this bug. ***