Hi, Adding bug-inetutils to CC along with the tarball that you sent me.
Oculytic <[email protected]> writes: > Hi Collin, > > I've got three security bugs to report to you within inetutils: > > 1. Heap overflow in whois > The "query_crsnic" function in whois/whois.c parses referral lines from > CRSNIC WHOIS server. The allocation uses strlen(p) + 1, but the copy loop > ignores '\0' and stops only on CR/LF. If a malicious WHOIS server or a MiTM > on plaintext TCP/43 returns a "Whois Server:" line without \r or \n before > the local fgets() buffer terminator, the loop walks past the NULL byte and > copies adjacent stack data into the heap allocation, overflowing "ret". > This results in a client-side heap overflow. > One of the scripts attached will run a server that will trigger the > overflow. This will be easily visible on an ASAN build. > > The fix is to include "*p != '\0'" in the copy condition. Thanks, I'll fix that one in a bit. > 2. Terminal Escape injection in whois > In do_query, only the CR/LF characters are stripped before printing > server-controlled output. This allows for terminal escape sequences. > Depending on the terminal being used, different OSC terminal sequenes can > result in all sorts of issues. In the past, vulnerabilities in terminals > have allowed memory corruption from these terminal escapes. One of the > scripts attached will run a server that will trigger colouring and > malicious hyperlinks in an Ubuntu terminal. > > The fix is to filter or visibly escape control characters before printing, > except possibly safe whitespace like tab. Do any other WHOIS clients do this? If not, I don't really think it is an issue. RFC 3912 explains defines the protocol as using ASCII, but for historical reasons it may be other encodings. Also, it details the lack of security in the protocol. > 3. Traceroute global buffer overflow > Traceroute is often a setuid binary on many systems as it makes network > calls that would usually be privileged. Because of this, vulnerabilities > from a local perspective are interesting. > The traceroute binary has a commandline flag to supply multiple gateways > using "-g". > > When traceroute builds IPv4 loose-source-route options in global > ip_opts[MAX_IPOPTLEN] (40 bytes), the while-loop guard checks IPOPT_OFFSET: > while (gateway && *gateway > && optbase[IPOPT_OFFSET] < (int) (MAX_IPOPTLEN - sizeof (struct > in_addr))) > > But inside the loop the code writes at optbase + optbase[IPOPT_OLEN] and > only increments IPOPT_OLEN: > memcpy (optbase + optbase[IPOPT_OLEN], > &((struct sockaddr_in *) res->ai_addr)->sin_addr, > sizeof (struct in_addr)); > optbase[IPOPT_OLEN] += sizeof (struct in_addr); > > IPOPT_OFFSET is initialized once and never advanced, so the loop guard > never reflecst the actual write offset. Supplying many -g gateways cause > 4-byte attacker-controlled writes past the end of ip_opts. > > A trigger is: traceroute -g 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 > google.com > > A fix is to bound writes using IPOPT_OLEN, not IPOPT_OFFSET, and reject > excessive gateways before copying. I submitted a PR for this one, thanks [1]. Collin [1] https://codeberg.org/inetutils/inetutils/pulls/24
servers.tar.gz
Description: application/gzip
