Hi,
can we get a statement regarding the status of these vulnerabilities?
https://seclists.org/fulldisclosure/2020/Apr/7
Thanks.
Hi,
can we get a statement regarding the status of these vulnerabilities?
https://seclists.org/fulldisclosure/2020/Apr/7
Thanks.
those seem more like bugs than security vulns.
An authenticated user can crash the console process via a crafted packet.
I’m not seeing a vuln here. I would be much more concerned about an authenticated attacker. An attacker that is authenticated isn’t looking to crash the console process.
While the severity and impact of the vulnerabilities can be discussed, I would still like an official statement.
Especially since the bug/security vulnerability report was (according to the timeline in the mail) accepted (in the sense of confirmed and a patch mentioned) and then all communication to the reporter were cut afterwards.
IMO, this is not how security researchers should be treated, and just because the vulnerabilities were not critical in this case (which we don’t fully know, a memory corruption can easily lead to code execution) the report should still be treated seriously.
Dont use their routers if you are not comfortable… Email them directly if you have concerns.
Send a supout showing the corruption after it occurs.
Read “Responsible disclosure of discovered vulnerabilities”
https://mikrotik.com/support
Personally “authenticated user can do x” (meaning administrator) is complete nonsense.
So I personally do not agree with this. What we see in term of security now is that one flaw that can allow for RCE or Elevation of privileges can be used in chains to attack a target. A vulnerability or a “bug” that is considered none critical can become a part of this chain and for this reason become important to fix. Now I did not read in this specific target what this means but if someone figures out how to get a console via webgui or other method they could use this to perform a RCE as a crash is only a matter of time from being used for RCE unforgettable. So we have gone from ignoring privilege escalation to focusing a lot on them but primarily for Windows as there is where the real problem is currently.
So in this case the risk is most lightly to be low and using the exploit without being a admin already is complex or currently not possible. I do not however consider these types of bugs a nonsense and your message should not be that either. Ask Apple how they feel about the Virus free ads today for instance.
You should say that the risk is low and if you are following security guidelines for protecting your router this risk is lower then low.
How is this different than any other regular bug, that causes a crash? Are all bugs vulnerabilities now?
From what I can see in the security landscape bugs that cause a crash in a important process like console or similar is often targeted for RCE. This can not always be used and you have to look at the ease of use. What is more of an issue now is the used of chained attacks. You can now find reported RCE where the chain of exploits are more than 15 and many of these 15 are not considered critical or even medium but chained together they become a problem. So it depends on the nature of the bug I would say but a crash in a critical process like console I would say could be an issue.
IPSec not not behaving as it should is perhaps not.
My point is not that this issue here is a problem or not is that communication from support should not be “This is nonsense” it should be “We categorize this as a Low risk and a potential attach chain would be complex as currently there is no known exploits in use”.
I love your products and software but I do not agree with the word nonsense in this case.
I already provided the link to MikroTik responsible vulnerability submission guidelines. Once the issue is properly submitted to the correct place, it will be analyzed.
My personal opinion about what is a bug, and what is a vulnerability was just an aside.
From what I read this can’t be reported through the vulnerability page of Mikrotik because you the user is already logged in.
It should then be reported as a bug to: support@mikrotik.com
Everyone can do that and refer in their support request to the page describing this bug.
By the way, the bug is already accepted and will be fixed, like any other crash.
Oof…that saves a lot of responding to support e-mails for Mikrotik. ![]()