As not to scare anyone, this is not a security vunerability! This requires a “special” installation onto the router, and at that point allows you to access the underlying linux system.
This can NOT be done remotely! This is NOT a security issue at all! The ONLY way to use this vunerability is IF you have the mikrotik in your possession.
We have researched the exploitation claim in first post of the topic.
We can find no basis for this claim “Exploitation of this vulnerability will allow full access to the router device.” Following these instructions will NOT allow access/control of the router and will NOT allow further efforts to enable access/control of the router.
By following the instruction for the first "sshd heap corruption”, the sshd service of the router will exit and will not restart. This is a denial of service as only a reboot of the router will make the ssh remote management service available again.
The second method that causes a crash of the sshd program also provides a denial of service as the sshd does not restart and the router requires a reboot to have sshd available. It does not allow or make it possible for further efforts to gain access/control of the router.
To protect yourself from the denial of sshd service (so that you can always use ssh):
For those users that do not wish to upgrade:
For home users that use the default firewall configuration (comes preset), there is no reason to upgrade as the default firewall does not allow access to management interfaces from the interface connected to the internet.
For network administrators that do allow ssh access to the router, it is advised to add firewall rules to restrict access to trusted ports or disable ssh management.
For users that would like to upgrade:
RouterOS v6.3 and v5.26 has already fixed this issue.
As always, the security of RouterOS is our main concern, and we continue to research bug reports.
Throwing random data at a vulnerable router will just crash the SSHD, but a targeted exploit could definitely compromise the router if SSH is available remotely.
My compliments to Mikrotik for responding to this with patches in a timely fashion. I haven’t tested them yet, but I will.
R1CH is absolutely right. There is a long history of vendors claiming that a “crash is just a crash” but if you spend any time with exploit development it becomes clear that many overflows provide a mechanism for an experienced attacker to execute arbitrary code. It’s not as difficult as you might think, especially if you have ever written code in environments where you had to really understand the nuances of things like page alignment and memory allocation.
I’m a user and fan of ROS, and recommend it to many people, but when it comes to security vulnerabilities, it is important to set aside personal feelings and take time to understand the implications.
Describing the implications of security vulnerabilities should never be construed as an “attack” on your favorite product. Remember that every iPhone jailbreak started with something crashing when it shouldn’t.
I agree, but in this case, we specifically researched this in detail, we do not take this kind of claim lightly, and we would not post a response like this, without being sure.
