These are the files associated with the new ebuild for Quagga (0.99.10). There was regression though, the MD5 support for BGP has not been updated yet. Reproducible: Always
Created attachment 157329 [details] The patches for the ebuild
Created attachment 157331 [details] The ebuild for quagga 0.99.10
Created attachment 157335 [details] A security fix for the bgpd init script, binding to 0.0.0.0 causes security issues
Created attachment 157345 [details] A security fix for the init script, binding to 0.0.0.0 causes security issues
Created attachment 157347 [details] A security fix for the init script, binding to 0.0.0.0 causes security issues
Created attachment 157349 [details] A security fix for the init script, binding to 0.0.0.0 causes security issues
Created attachment 157351 [details] A security fix for the init script, binding to 0.0.0.0 causes security issues
Created attachment 157353 [details] A security fix for the init script, binding to 0.0.0.0 causes security issues
The issue fixed in the new upstream release is a DoS vulnerability in bgpd. Sargun, can you elaborate on the 0.0.0.0 binding change in the init script?
Currently the VTY binds to 0.0.0.0 (global, the world, etc). The VTY is the quagga management interface and it isn't meant for high load. Hypothetically someone could DoS this telnet based interface. Alternatively if someone took an out of the box Zebra and started it up with a weak password, it is immediately open to the world. Normally users will use a weak password because they assume that they are the only ones with access to the box. Its really "Secure out of the box" > "Ease out of the box" Also, the init scripts to not require the new ebuild, they are drop-in replacements.
By default, vty terminal is available only to root user of the box: apollo ~ # telnet hades bgpd Trying 217.156.27.2... Connected to hades.ineton.ro. Escape character is '^]'. Vty password is not set. Connection closed by foreign host. I really don't see how this could qualify as security vulnerability. I will deal with version bump as soon as I can.
Version has been bumped, with all USE flags as the previous version. No need to stabilize it since 0.99 is the development branch.
(In reply to comment #12) > Version has been bumped, with all USE flags as the previous version. > No need to stabilize it since 0.99 is the development branch. > Err, so this vulnerabilitty was only affecting the 0.99 branch, and 0.98 is safe and we can close this a noglsa since it's ~arch? because if it's not the case and 0.98 was vulnerable to this, we would need a fixed ebuild to stabilize.
I made a mistake in the new version by applying freeasform (aka bg4) patch while the new version already supports this without any patch. I've fixed that in 0.99.10-r1 revision. As for DoS problem being present in 0.98 versions or not... What I understand from that page is they had bugs in the previous AS4 code, but 0.98 versions do not have such support, ergo they should not be affected. However, if you find a security patch that needs to be backported, just let me know.
Instead of modifying the init script to hardcode the bind addresses, how about having a /etc/conf.d entries with defaults such as BGPD_OPTS="-A 127.0.0.1"? It would let us specify other options too. All those .init files should just include the proper ${daemon_opts}
