Consider removing the ability to perform unbounded queries using the 'show ...' option

[grobe0ba]

The show ... query is a useful option, however it grants a much greater opportunity for a potentially malicious user to craft a query designed to cause a denial-of-service in the single-threaded bird2 daemon.

Removing this option doesn't completely prevent this from being an issue, but it does reduce an attacker to the already more limited queries.

I wouldn't mind if this were behind a flag, but that obviously would cause significantly more work than the one-line patch of just removing it completely.

[xddxdd]

Since v1.4.2, the proxy component already limits BIRD commands to show protocol ... and show route ... by default: 8cbd6ed

Do you have any examples of command under show protocol ... and show route ... that might still cause DoS?

[grobe0ba]

I was not aware of this; apologies for not doing better research.

My understanding is that it may still be possible to construct a query that can cause DoS, but I don't have any examples. Now that I think about it, it seems likely that nothing on DN42 save the GRC would hold enough routes to make a DoS possible at all.

That being said, since you can still actually pass a custom filter { ... } argument the possibility still exists. I think the only way to completely avoid the issue is to explicitly ensure the input is a v4/v6 address for routes, or allowing text when performing an whois lookup.

[xddxdd]

Restricting the input to IP addresses will fix the issue, but will also block advanced queries that are not directly on the WebUI, such as filtering routes by tables, by BGP communities, etc.

Reading through BIRD's docs on filters, I don't see anything that can be easily abused. The only possibly abusable control structure is for loops, but BGP routes with large lists of attributes is rare, I don't expect it to be significantly performance impacting. Adding a rate limit for requests to proxy component is probably enough.

[grobe0ba]

Rate limiting does seem like the simplest approach.

The original reference for this all came down to a line in the documentation:

The user may still overload the daemon by requesting insanely complex filters so you shouldn't expose this socket to public anyway.

This seems to indicate that it at least theoretically possible to construct such a filter, but I think a bigger issue likely does come down to excessive requests, at least in the context of DN42 Looking Glasses exposed to the clearnet.