Yes, really, it's that serious!

It seems there is a bug in ROS that allows a remote attacker to crash any Mikrotik device if they can access it via v6. Even with firewalling you are still a sitting duck. Mikrotik have known about this for a year and have done nothing to fix it.

This information is due to be released to the public at UKNOF on 9th April. Yes, in 12 days anyone with a slight bit of knowledge about networks and a v6-enabled connection will be able to take any Mikrotik device (running v6) offline. No doubt an exploit script will follow soon after.

As a community it is absolutely critical that we push Mikrotik for a solution to this problem as a matter of upmost urgency. The consequences of this getting out into the wild before a fix is available would be disastrous for all of us. Please everyone pay attention and help in making sure Mikrotik understand just how critical this problem is.

There is a thread already running on this (viewtopic.php?f=2&t=147048) but the subject is such that most people will probably skip over it.

UKNOF presentation where this issue will be disclosed in full:https://indico.uknof.org.uk/event/46/contributions/667/
CVE report:https://cve.mitre.org/cgi-bin/cvename.c ... 2018-19299

Somehow this is the first I've heard of this and I'm very concerned as I have a modern network that includes IPv6. You're saying Mikrotik have known about this for50 weeksand it hasn't been fixed?!? What is going on over there?!

This is a completely unacceptable response for a security vulnerability. I think it's time for me to start moving away from RouterOS, either to OpenWRT or a different vendor that cares about security.

This is also a new one for me...will be digging into it

Something similar (if not the same)had been already discussedin this forum.

This is also a new one for me...will be digging into it

In a nutshell, it's a memory exhaustion issue. You send a v6 packet formed in a certain way (which I assume will be revealed on 9th April) to a Mikrotik router and the kernel leaks a bit of memory. When memory runs out the router crashes, I assume until the watchdog reboots it. There is no way to firewall as whatever this characteristic is that causes the problem can be set with any v6 packet.

Something similar (if not the same)had been already discussedin this forum.

I believe that thread refers to CVE-2018-19298 which is a similar incident. The later one (CVE-2018-19299) is far more sinister.

Even if there is no way to firewall it on a MikroTik, i'm assuming that once we know what is being set in the packet header, it can be mitigated with another solution based on flow detection and dropping the traffic in a switch. That won't work for everyone obviously, but it would work for a lot of the ISP and DC networks I consult on.

Let's hope MikroTik can have a build ready with a fix before the full details of this go public...

Let's hope MikroTik can have a build ready with a fix before the full details of this go public...

That is exactly what we are all hoping for. Unfortunately the silence from Mikrotik does not fill me with confidence that they even understand how bad this problem could turn out.

Mikrotik have known about this for a year and have done nothing to fix it.

If this is true, then WTF are they even thinking?!
This only sends all the bad messaging: If you want a bug to be fixed, release it as zero day exploit. Doing it nice and proper way gets you nowhere...

Something similar (if not the same)had been already discussedin this forum.

In this thread there two issues listed: nd cache & routing / stateful connection exhaustion. Which is is referred here?

首先可以减轻一些防火墙范围h most end users will use. For non-end-user, address restrictions can help / resolve issue.
Second wasn't clarified what the actual issue was.

I'd like to add my voice to the Mikrotik community stating this must be addressed before public release.

Tim

Thankfully I'm in the position to do the above (and just have on my edge routers, in fact). I am nothing short of apoplectic that I've had to, however. Secretly hoping that either 6.44.1 was a fix for this or that it's a complete hoax. Either is better than what appears to be reality.

Edit: It really is about time v6 stops being such a second-class citizen on RouterOS. I'm a proper advocate for it but when MikroTik pull this kind of stunt it makes you start questioning your decisions.

Code:Select all

/ipv6 export file=hahahanoipv6foryou.rsc /system package disable [find name=ipv6] /system reboot

Thankfully I'm in the position to do the above (and just have on my edge routers, in fact). I am nothing short of apoplectic that I've had to, however. Secretly hoping that either 6.44.1 was a fix for this or that it's a complete hoax. Either is better than what appears to be reality.

Edit: It really is about time v6 stops being such a second-class citizen on RouterOS. I'm a proper advocate for it but when MikroTik pull this kind of stunt it makes you start questioning your decisions.

Guess we won't be deploying IPv6 Q2 2019

Interesting to say the least.

We have quite a number of networks we have deployed IPv6 into.
I always wish when things like this happened I knew more to be able to protect our clients - but of course that is the nature of the beast.

Hoping Mikrotik can patch the issue.

IPArchitects has a decent idea in regards to switch path in front of the routers as a possible solution to help direct traffic.

Time will tell I guess

Yes, really, it's that serious!

Thanks for info

Mikrotik have known about this for a year and have done nothing to fix it.

shock for me

Don't worry you can use kid control on your core routers to block them.

Seriously though, what is up over @ MT ?

IPv6 isn't even out of beta yet, so no worries.

Glad I have not even turned on ipv6 packages yet, that link from mkx was back in 2017?? 50 days, how bout 2 years.

事实仍然有问题。叙述,响应e and criticism over this issue has gotten way ahead of the information available. Specially crafted packet / memory exhaustion issues (or any other vulnerability) are nothing new to even the largest network equipment manufacturers. They can be dealt with, and are done so routinely.

The common practice to go public with a vulnerability is to do it in coordination with affected vendor, and their release of a fix. To do otherwise is irresponsible and unprofessional.

事实仍然有问题。叙述,响应e and criticism over this issue has gotten way ahead of the information available. Specially crafted packet / memory exhaustion issues (or any other vulnerability) are nothing new to even the largest network equipment manufacturers. They can be dealt with, and are done so routinely.

The common practice to go public with a vulnerability is to do it in coordination with affected vendor, and their release of a fix. To do otherwise is irresponsible and unprofessional.

definately agree

This is a total disaster for mikrotik's future if they do not fix, before customer impact. EVERYTHING we deploy last years have ipv6, most are ipv6 only, some dualstack

The common practice to go public with a vulnerability is to do it in coordination with affected vendor, and their release of a fix. To do otherwise is irresponsible and unprofessional.

If vendor knows about it for over a year and do nothing?
You are actually right: That is irresponsible and unprofessional - from vendor!

Hi,

I'm Marek Isalski.

I've been trying desperately to get MikroTik to resolve this issue since they acknowledged it on 2018-04-20. I know for a fact other people have figured this vulnerability out, and I believe I've seen exploitation of it in the wild in the last 2-4 weeks. MikroTik's response to my belief that there is exploitation going on was along the lines of "let's not jump to conclusions".

I have told MikroTik I am discussing these vulnerabilities at UKNOF — they didn't seem to care because they've repeatedly told me this is "just a bug".

See you all at UKNOF 43 — which has a live web stream.

Good luck, everyone.

Thankfully I'm in the position to do the above (and just have on my edge routers, in fact). I am nothing short of apoplectic that I've had to, however. Secretly hoping that either 6.44.1 was a fix for this or that it's a complete hoax. Either is better than what appears to be reality.

Edit: It really is about time v6 stops being such a second-class citizen on RouterOS. I'm a proper advocate for it but when MikroTik pull this kind of stunt it makes you start questioning your decisions.

My slide deck for UKNOF 43 includes screenshots of me crashing 6.44.1.

The common practice to go public with a vulnerability is to do it in coordination with affected vendor, and their release of a fix. To do otherwise is irresponsible and unprofessional.

I have been asking MikroTik for exactly this approach for nearly a year. They will not commit to a date, or even that they have begun work on it. The timeline will be made clear in my talk at UKNOF 43 — which MikroTik were made aware of well in advance.

Additionally I've been working with CERTs and other trusted ops groups to spread the word in advance, and was hoping that the likes of NCSC UK or NCSC NL would be able to mediate between myself and MikroTik as I view responsible disclosure as a priority.

Sadly I also believe there is exploitation in the wild — certainly in the last 2-4 weeks — and have shared this with MikroTik. They continue to view this as a "bug" not a "vulnerability".

why r u being so disruptive and trying to break mikrotik?

why r u being so disruptive and trying to break mikrotik?

这就是security researchers do. Any internet connected device and protocol is studied for such bugs, and finding and fixing them makes everyone safer. Be happy that he found it before the bad guys did. Imagine someone constantly crashing your network and your firewall can't seem to do anything to stop it. They demand $5000 in bitcoin to stop the attack, no one knows how it's happening and Mikrotik can't help so you have to pay before you lose all your customers...

The issue was disclosed privately to Mikrotik 50 weeks ago. It should have been fixed 49 weeks ago, but it seems Mikrotik doesn't prioritize vulnerabilities until they are actively exploited, so here we are.

这就是security researchers do. Any internet connected device and protocol is studied for such bugs, and finding and fixing them makes everyone safer. Be happy that he found it before the bad guys did. Imagine someone constantly crashing your network and your firewall can't seem to do anything to stop it. They demand $5000 in bitcoin to stop the attack, no one knows how it's happening and Mikrotik can't help so you have to pay before you lose all your customers...

The issue was disclosed privately to Mikrotik 50 weeks ago. It should have been fixed 49 weeks ago, but it seems Mikrotik doesn't prioritize vulnerabilities until they are actively exploited, so here we are.

Very well said R1CH!

It's possible that this issue may be Kernel level and the only way to fix that could be v7 with the updated kernel. This may be why they've done nothing about it to date - because they can't on the current kernel.

why r u being so disruptive and trying to break mikrotik?

Multiple MikroTik staff have repeatedly and continuously called this a "bug" and not a "vulnerability". If reporting "bugs" is now deemed disruptive then could someone please stop the world, because I would like to get off.

Meanwhile, industry press is now calling me a "security researcher" but the bigger side of the story is that I am a network engineer. I have spoken at conferences, industry associations, network operators groups, and even a MikroTik MUM, about MikroTik and RouterOS and how to use these products to improve network reliability and security. My company has loads of MikroTik devices deployed in production in our provider network, and we look after many more in customers' networks. MikroTik has been our "go-to vendor of choice" for several years now. Some of my colleagues might go so far as to say I have been evangelical about their product line and network operating system.

I am utterly broken-hearted at MikroTik's response to this problem.

If its not fixed by now, it is probably kernel level.
I think MT usually reacts quite fast to security patches etc.. If this one is not patched for 50 weeks time, than there has to be something in the old linux kernel preventing it.
Just a guess..

Yes, it is kernel level and is very hard to fix, since RouterOS v6 has an older kernel version and we can't just change the kernel.

Let's merge the topics:
viewtopic.php?f=2&t=147048