On Mon, 21 Nov 2016 18:08:39 +0100 walter harms <wha...@bfs.de> wrote:
> but i have an other question, based to the comments in the code: > > * The arguments are combined and sent as one write operation. Note > that > * IE will puke big-time if the headers are not sent in one packet > and the > * second packet is delayed for any reason. > > the only reason we need to buffer everything is because of IE > whatever. Can someone confirm that this is still needed ? My observations are: - the format string is not externally controllable (OFF_FMT is build time macro) - range_start, range_end and file_size are of type off_t (numeric) and rigorously checked earlier. Attacker does not have arbitrary string control over them. Thus, there is strict upper bound on the generated string. So this does not look like exploitable. It's not even a bug if IOBUF_SIZE is guaranteed to be larger than maximum generatable string. It is still good practice to fill it with snprintf. If this is done, proper error checking should be done to check the final 'len' that it does not exceed IOBUF_SIZE or you have information leak bug (since snprintf returns the length it would generate if buffer was unbounded; not the length it actually wrote to the buffer). /timo > > re, > wh > > Am 21.11.2016 16:50, schrieb Jody Bruchon: > > On 2016-11-21 09:53, Raphael de Carvalho Muniz wrote: > >> We understand that the resulting program may have vulnerabilities > >> when the macro "#if ENABLE_FEATURE_HTTPD_RANGES" is enabled, by > >> the fact of utilization that sprintf() function. Second the CWE > >> Project, is the classified by CWE-134, where the use this function > >> that accepts a format string as an argument, but the format string > >> can originate from an external source. > >> > >> Still second the CWE Project, this vulnerability can cause > >> consequences related a with confidentiality, integrity and > >> availability, like allow for information disclosure which can > >> severely simplify exploitation of the program and the execution of > >> arbitrary code. > >> > >> We'd very grateful if you could say to us if are you understand > >> this how a vulnerability and if you have a motivation to correct. > >> > > I'm offering up this patch to fix the problem you've reported. I > > haven't tested it but it should be functionally identical and close > > the most obvious sprintf security holes I found on a cursory > > examination. Hope this helps. > > > > -Jody Bruchon > > > > > > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
