VyOS Networks Blog

Hello, Сommunity!

VyOS 1.3.5/Equuleus LTS release is now officially available for download for customers and contributors. It includes fixes for two security vulnerabilities and a few bugs. One vulnerability is related to the HTTPS API, and the other is in the BGP daemon. Even though they require specific configurations and conditions to exploit, we encourage everyone to update. Images for on-premises deployment and for upgrade are already available, and cloud marketplace listing updates are in progress.

Possibility to start the HTTPS API service with a default API key

We discovered an unintentionally left hardcoded default key in the HTTPS API server implementation that becomes active when the config has no API keys set. Such configurations were supposed to be the default VyOS configuration was unaffected because it has the HTTPS API disabled, and we do not have any information about vulnerable systems in the wild. Any system that had at least one API key configured has been secure. However, it was possible to create an insecure configuration that would use the undocumented default key.

When we first added the HTTPS API implementation to VyOS 1.2.x, an unfortunate line from an early prototype slipped through the cracks and made it into the mainline codebase. Of course, the default data dict was supposed to have only port and debug settings, but a default API key we used for testing ("qwerty") got included together with it. It was me who overlooked it and I accept full responsibility for that (and moments like that do make me want to step down as a maintainer, I have to admit).

The usual HTTPS API server config includes one or more keys:

# show service https 
 api {
     keys {
         id automation {
             key 13oERPhVytWC6eRmVUAT
         }
     }
 }

If any keys were defined in the config, that piece of default data got overwritten and never made it to /etc/vyos/http-api.conf. Thankfully, that was the case for all configs we have seen in the wild. But insufficient validation allowed the user to commit a configuration without any keys:

# set service https api
# commit

And that is the case when the API server unintentionally had a default password — analogous to the fact that it is possible to enable SSH when the default account (vyos/vyos) is not reconfigured for a more secure password yet, only in this case that behaviour was undocumented, unintentional, and unjustified.

The issue was discovered during an internal audit by Christian Breunig — hopefully, before it came to the attention of any malicious actors. We notified the subscribers immediately and received quite a few responses, but no one reported a vulnerable configuration and we haven't received any information that would suggest that this issue was ever exploited in the wild. Still, now it is fixed in the rolling release and in 1.3.5 — there is no default key anymore, and a configuration without at least one key is impossible to commit.

Of course, it is natural to ask what we are doing to prevent similar issues in the future. We do have good news for you in that regard.

First, that change was pushed before the current code review system was in place. Now, it is impossible to push code directly into any of our LTS branches: any new code only gets in through a pull request and approvals from at least two different maintainers other than the pull request author.

Second, the testing infrastructure was still in its infancy and would not allow to test for that. Now it does, but one lesson we learned from discovering this is that we need to write more negative tests that ensure that invalid configurations actually cause commit errors as expected.

Finally, we would like to encourage everyone to read the VyOS source code and report anything you find suspicious to us. People who help us test VyOS and keep us secure can get contributor subscriptions, as always!

Denial of service in BGP

A number of  vulnerabilities were discovered in FRR that might allow a remote attacker to crash the BGP daemon by sending a specially crafted update. Those vulnerabilities were found by fuzzing and there is no evidence that they were ever exploited or that they are practical to exploit in real-world environments, but this release includes fixes for them to make them impossible to exploit.

Bug fixes

Apart from those security patches, this release includes fixes for a few more bugs.

• Changing the VXLAN port had no effect until reboot, now port changes are correctly applied immediately (T5669).
• Bridge member option now correctly disallows uppercase interface names (T5670).
• show log vpn all and show log vpn ipsec operational mode commands work correctly again (T5714).
• PPPoE MRU is now set to the MTU is not specified explicitly (T5630).
• Fixed an imprecise config file name check in the load command (T5763).
  
  

That's all for now, but stay tuned for updates: we will also release VyOS 1.4.0-rc1 for everyone to test soon!