These are the seatbelts and airbags of the software world. These numbers are unheard of in operating systems or (Web) browsers. Its just a sign that they’re not trying,
https://www.reddit.com/r/mikrotik/comments/cqksvr/these_are_the_seatbelts_and_airbags_of_the/
How it is a all a misunderstanding, how they did not see it necessary to respond to emails because there is no issue, and how v7 will fix them all…
Sounds like flawed data in the article. There are no known unfixed vulnerabilities. If there are, please point them out.
We have also published responsible disclosure guidelines, and are following up on all reports sent to security@mikrotik.com . https://mikrotik.com/support
Bad article, and what Normis said.
What is he even referring to?
Is it a reply to some paper discussing number of vulnerabilities in router products?
Where is it to be found?
This is not discussing a particular vulnerability, but it is examining what defense-in-depth procedures are in use. It seems all vendors are doing a very poor job here, not just Mikrotik.
As an example of what this means: without ASLR, a router will load the code at the same location in memory every time. This makes writing an exploit much easier, since you can simply tell your exploit code for example “jump to address 0x0129cf00” where 0x0129cf00 contains some sensitive function (eg setting a password, turning off firewall, whatever). With ASLR, the addresses would change on every startup. This means the exploit has to then use more complex code to figure out where the code it wants to use is actually stored. The bigger and more complicated the exploit payload is, the more chance it will have bugs and fail, and it may no longer fit into a single packet which may be a constraint to exploitation.
It should also be noted that all the options mentioned in the article are compiler options. Ie, to benefit from their security, all you need to do is turn them on and the compiler adds them to the binary automatically - the protections will have no impact on functionality of well-written code. There may be small performance loss as for example the stack check will examine the stack at the end of each function to check for overflows (signs of an exploit attempt), but these are small trade offs for the vastly improved security. Every modern OS such as Windows 10, Linux, etc uses NX stack, ASLR, etc by default, RouterOS should consider it too.
There are many things that can be done to reduce the attack surface.
I think as a first thing I would consider not running all processes as root, use chroot to limit their filesystem view, etc.
Maybe also other finegrained security features in the Linux kernel can be used.
When a good mechanism is in place, it could also be used to run user-supplied binaries on the router to extend the functionality beyond what MikroTik wants to offer.
How many of these vulnerabilities though are still present when a competent person configures the router?
That is completely unknown. MikroTik state that there are no known (to them!) vulnerabilities at this layer, however that does not mean there are no vulnerabilities that are not yet known or are only known to certain other people.
This may be true, but my interpretation from the linked article is different - what safeguards have been put in place to avoid future vulnerabilities?
I think the wording used here is good - no known unfixed vulnerabilities. This is very different different than saying ‘bug free’, or ‘contains no vulnerabilities’. I personally care a lot more about what you are doing to improve your posture as you move forward and how you handle disclosure than the simple fact of whether you have a given vulnerability or not.
If your WAN is entirely firewalled against incoming connections (including VPNs) then your risk is only coming from the LAN side which is generally a lot safer. That shouldn’t be a reason not to include exploit defense in the compiled binaries though.
Most persons configuring things in this world are not competent, including you and me, that is why we ask these questions.
“Assumption, the mother of all…”
https://www.cloudflare.com/learning/security/glossary/what-is-zero-trust/
https://hackernoon.com/the-rise-of-zero-trust-architecture-17464e6cbf30
Sounds like flawed data in the article. There are no known unfixed vulnerabilities. If there are, please point them out.
I’m actually surprised (not actually, Mikrotik has built at reputation of ignorance of downplaying questions like this, however speculative) Normis simply can’t state that they already do this or will look into it, but instead tries to refute a seemingly obvious opportunity if not already managed. This for example would be an one off statement by Mikrotik whether they do it or not and why.
Just like Spectre and Meltdown, every additional compilation slows down code and it is far from obvious to add hardening to proprietary end of life kernels used by Mikrotik.
If someone doesn’t like my views the just ask Mikrotik to control the narrative by stating this method is already implemented in their code, questions like this can either be asked by others or handled in an assuring manner by Mikrotik, this discussion could also be transacted on a platform not managed by Mikrotik.
Well that holds for vulnerabilities in the configuration interface (webfig, winbox, telnet/ssh) which have been most common lately.
However, there may just as well be vulnerabilities in the services that handle incoming VPNs. When you now use e.g. an L2TP/IPsec VPN to secure your incoming configuration connections and/or to allow you to work on the local network while on the road, and next week a vulnerability in the handling of that protocol is disclosed, you are in trouble anyway.
There can also be bugs in the connection-tracking firewall. We’ve seen the recent fix for connection tracking in GRE (which resulted in uncovering errors in many people’s firewall setup).
I found an article here: https://securityledger.com/2019/08/huge-survey-of-firmware-finds-no-security-gains-in-15-years/
I also looked at the website of the organization that did the report and didn’t see anything about it. https://cyber-itl.org
These are all features that I would have expected the various vendors to be aware of and have implemented.
The response that Normis gave is equivalent to saying, “I don’t have AIDS” when he should be able to be saying, “I don’t have AIDS and I always wear a condom too.” We don’t just want Mikrotik to be looking for and fixing vulnerabilities, we also want modern development and design practices that prevent vulnerabilities in the first place.
To be fair, the other companies shown aren’t doing a great job with this either, and the Linux kernel itself probably should do better. (Although I have been told that recent Linux kernels are better in this respect than older ones were.)
Implementing features like stack guards, ASLR, and RELRO would ultimately help Mikrotik as well, because it will prevent some vulnerabilities and then Mikrotik won’t have to scramble to fix them and get patches out. In other words, if they don’t have to fight so many fires, they’ll have more time to work on more interesting things.
“I don’t have HIV, according to the latest HIV test taken 17.08.2019, in addition to always requiring the use of a condom.”
Yes, that’s more precise. 