Hi Tim, On Tue, Apr 21, 2020 at 03:18:43PM +0200, Tim Düsterhus wrote: > Willy, > > Am 02.04.20 um 15:03 schrieb Willy Tarreau: > > The main driver for this release is that it contains a fix for a serious > > vulnerability that was responsibly reported last week by Felix Wilhelm > > from Google Project Zero, affecting the HPACK decoder used for HTTP/2. > > CVE-2020-11100 was assigned to this issue. > > > > There is no configuration-based workaround for 2.1 and above. > > > > This vulnerability makes it possible under certain circumstances to write > > to a wide range of memory locations within the process' heap, with the > > limitation that the attacker doesn't control the absolute address, so the > > most likely result and by a far margin will be a process crash, but it is > > not possible to completely rule out the faint possibility of a remote code > > execution, at least in a lab-controlled environment. Felix was kind enough > > to agree to delay the publication of his findings to the 20th of this month > > in order to leave enough time to haproxy users to apply updates. But please > > do not wait, as it is not very difficult to figure how to exploit the bug > > based on the fix. Distros were notified and will also have fixes available > > very shortly. > > > > The write-up is available now: > https://bugs.chromium.org/p/project-zero/issues/detail?id=2023 > > It has a "Methodology-Fuzzing" label, so after CVE-2018-14645 and > CVE-2018-20615 this is the 3rd CVE within H2 found using fuzzing that > I'm aware of. It probably won't be the last. Can we please allocate some > resources on making HAProxy more fuzzer friendly after 2.2 is out?
Well, at the risk of sounding annoying I'm afraid not on my side. I mean, it's already extremely hard for all of us to invest enough time on the features that people want, to review contributed code and to fix bugs to keep the code in a stable state. It's like in any other opensource project, it's simply not possible to ask for something to be done to see time suddenly appear out of nowhere. Making the code "more fuzzer friendly" means everything and nothing at the same time. It's already getting more fuzzer friendly thanks to a much better layering and modularization that allows certain parts to be more easily tested (hence the example you gave on how you could test hpack). On the other hand, it also comes with some limits, and the ability to develop, extend and maintain it is the most important aspect that will always prevail when a choice needs to be made. And quite frankly trying to untangle a layer7 proxy so that dynamic parts can be run out of context will drive us nowhere just because by design that doesn't correspond to what the code needs to do. Testing proxy code is very hard. It's no surprize that varnishtest (now vtest) was purposely written from scratch for this and is only used for testing proxies. Maybe new external tools are needed and we'd need a better way to interface with them, I don't know. There certainly are some parts that could be improved regarding fuzzing, I honestly don't know. But I can't guess it by myself either. However I'm willing to accept some patches if: - they don't affect maintainability/development - they don't affect performance Last, it's important to keep in mind that the number of issues that are really subject to such tools and methodologies is extremely low. Looking since 1.8 (where the bug mentioned here was introduced 2.5 years ago), no less than 520 bugs were fixed, 4 of which were tagged as critical and required a coordinated fix (and all 4 in code I wrote myself). Half of them were found using fuzzing, it's not even certain the two others could have been found this way. However I don't want to see that the time invested to improve fuzzing results in less efficiency at spotting and fixing all the other ones because in the end each bug affects some users. I'd personally see more value in investing time to write Coccinelle scripts to spot coding mistakes that happen all the time and especially when developers are tired or disturbed, and which often result in the same issues as those detected through fuzzing. That doesn't mean I'm not interested in fuzzing, it's just that I don't see this main goal as the most valuable way to invest time for all those already deeply involved in the project, but I'm happy to be proven wrong. > I would also be interested in how Felix Wilhelm performed the fuzzing, > do you happen to have details about that? No, I only got the information that was just made public. But do not hesitate to contact Felix about this, I'm sure he will happily share some extra information to help us improve our side. Regards, Willy
