A vulnerability in MikroTik RouterOS allows an unauthenticated remote attacker to force a router to reboot. This is done by sending a packet of the size of 1 byte to RouterOS's IPv6 address using IP proto 97. All versions of RouterOS with EoIPv6 support are likely vulnerable to this attack. This attack required target system to have IPv6 enabled and had at least one tunnel interface present.

https://github.com/Nat-Lab/CVE-2018-5951

Tested Versions
RouterOS 6.39.3 (Bugfix only), 6.41 (Current) and 6.42rc11 (Release candidate) are tested, and all of them are vulnerable to this attack at the time of writing. This vulnerability is likely to present in the older versions of RouterOS with EoIPv6 support as well.

Is this real vulnerability? Almost current versions are included?

you can partially mitigate this by setting up an ipv6 input firewall rule to accept only packets from known & configured & trusted EoIPv6 peers.
one might "guess*" your IPv6 address, but guessing also the right src address seems be highly unlikely to me.

*guess: pick the right one in 2^64 possible combinations. i know, autoconfig's ff:fe cuts this down to 2^48 and usually folks pick "easy to remember" addresses, and you still have the "subnet router anycast address" (xxxx::0) to get your packet delivered to the router.

of course, if you also know the source and can spoof a packet with the right src IP, _and_ get it delivered, a selective drop will not work for you.

still you can use IPSec ESP to wrap your EoIPv6 into a protective layer, where spoofing has no chance to succeed.
also, using unicast RPF wherever possible can quite limit the possible attack points.
or just use a more generic ipv6 filter rule to drop all packets with protocol=97 and packetsize<size of an ipoev6 encapsulated minimum sized ethernet frame

Interesting, if you call something that just uses your resources "a vulnerability", when you can clearly protect your device against this (like with firewall), would you also call Chrome a vulnerability? It uses tons of RAM on my machine.

Interesting, if you call something that just uses your resources "a vulnerability", when you can clearly protect your device against this (like with firewall), would you also call Chrome a vulnerability? It uses tons of RAM on my machine.

Does chrome bring down your business by allowing remote attackers to constantly reboot your routers though? High memory usage in chrome can't even cause your pc to reboot.
How can people have faith in these products for business critical work?

How can people have faith in these products for business critical work?

You would advise them to buy Cisco ASA instead???

How can people have faith in these products for business critical work?

a reasonably big cisco network with ~90 asr9010 routers experienced random line card reboots and therefore outages without any good reason. incidents followed each other randomly, but sometimes after just couple minutes, essentially creating some chain-reaction like effects: routers connected to each other via long-haul transmission connections, but otherwise up to 100km apart from each other just suddenly died within minutes. no one could tell why. the issue repeated itself - the only resolution was to power-cycle the boxes using out-of-band management. a reboot meant 30-40 minutes(! correct, minutes, not seconds) time taken to recover.
some even suspected cyber-criminal activity or cyber-terrorism must be behind it.
all the linecards were replaced (that is a bit over 250 pieces) with next generation ones as repair.
later it was found and demonstrated, that the packet parser mistakenly identified an ethernet frame carrying an ipv4 packet as ipv6 packet, branched to the wrong point on the NP, resulting a processor lockup - a situation from where the device cannot recover, not even with the implemented watchdog.
total secrecy was kept, not even the owner & operator of the network was told the exact mechanism and conditions how the bug could be triggered.
several months later the issue was disclosed as "severity 2 DDTS" with the appropriate patches.

and look, even after the effect, we still see some NP lockups in the network, caused by other mis-parsed packets, but until now the NPUs were able to recover from it using "fast reset" - resulting a couple of second outage, instead of turning unresponsive. does that mean, all the issues got fixed? actually no, it's just an automated workaround.

bottom line: routers are computers, running software people write, even if they test lots of things, there's nothing like live production network, where shit just happens. regardless of the make.

i could have been whining at the TAC hours long because most of the "cisco enterprise APs" were affected by the WPA2 issue and there was no software fix available, even after weeks the bug was publicly disclosed. and look, RouterOS current & bug fix releases had the fix on the day of the disclosure. serious gear for serious business?

Interesting, if you call something that just uses your resources "a vulnerability", when you can clearly protect your device against this (like with firewall), would you also call Chrome a vulnerability? It uses tons of RAM on my machine.

Does chrome bring down your business by allowing remote attackers to constantly reboot your routers though? High memory usage in chrome can't even cause your pc to reboot.
How can people have faith in these products for business critical work?

Did you read my post entirely? A simple firewall stops it. Why don't you have it?

If a router surrendered after getting single one small packet, then it is definitely a thing that should be immediately corrected and not just mitigated by a firewall rule for ages.
Normis, if you confirm that behaviour, force the development to issue corrective version as soon as possible.

device with no password can also be immediately "hacked" by logging in and setting an unknown password. this is not a vulnerability, but a config issue.

nevertheless, this is a bug and we will fix it.

... that has been discussed before here, also recently:
devices that come with an empty default password (or, for that matter, any default password that is the same on every install, like admin/admin) and that allows continued operation without changing the password really is too big of a risk today.
something has to be done about that. at least force a password change on the first logon.

the firewall would be less of a problem when there was a default IPv6 firewall similar to the IPv4 default.
maybe it would even work without modification, when both ends consider input from an IPv6 peer to which they have sent EoIPv6 traffic as "established/related".
when in doubt one could insert an accept rule for incoming traffic from the peer IPv6 address.
unfortunately the IPv6 firewall is empty by default so it allows all input.

ipv6 is disabled by default.
if you enable it, doing a "system reset" will load an ipv6 firewall (ie. yes, a default firewall exists for ipv6, if the package is enabled)

ipv6 is disabled by default.

That should change... but that is another topic.

if you enable it, doing a "system reset" will load an ipv6 firewall (ie. yes, a default firewall exists for ipv6, if the package is enabled)

I would expect that when a previously disabled package gets enabled (or a previously not installed package gets installed),
its default configuration gets installed without doing a complete reset.

As it is now, it appears to be that the least that has to be done after unpacking a new MikroTik device is:
- set an admin password
- install or enable the packages one wants to use (like IPv6)
- update it to the current RouterOS and reboot
- install the included firmware
- THEN do a complete reset to defaults and reboot

I think there should be more guidance to force this procedure to be followed, as many new users skip one or more of these steps
and either they get hacked or later they find they have a sub-optimal default config and do not want to reset anymore because they
lose all the config work they already have done.

So I would suggest some more guidance in the QuickSet or other popup shown at first logon, that forces the user to change the
password, suggest to do an update, and after that does a reset to defaults again. Maybe an idea would be to keep some flag
if the user has done any config on the device (not the password setting) and if not, always do a reset to defaults after an update.

After all, now improvements in the default config make it in the deployed routers only very slowly. And some default config is not
applied at all.

Personally ... I don't want any configuration, have to reset them anyway. I connect with Winbox and set it up from there. However, I do understand that the first time connecting with a web browser, you'd need the MikroTik to have an IP, and that means at least some form of configuration.

So, since new MikroTik's will need a default configuration, upon login, provide a choice:

• Reset
• Apply example config 1
• Apply example config 2

And please don't force me to set a password or change it. In the lab, I can't stand that.

Perhaps force '/sys reset' to require an admin password?

Interesting, if you call something that just uses your resources "a vulnerability", when you can clearly protect your device against this (like with firewall), would you also call Chrome a vulnerability? It uses tons of RAM on my machine.

First the CVE is reserved but information is not official from what I can tell. Glanced over the github page in first post. Can Mikrotik Confirm or Decline that this is a problem as described.

Normis. Above statement does not in any words help us understand what we are up and against! Shame on you.
The thread starter does not say "a vulnerability" he says "Denial of Service Vulnerability". If this is the case, fix the interpreting bug so that the system can survive.

And Normis: Think of us ISP's a router is a router, it is NOT a firewall. We can't use firewall rules in your product as it disables FastPath.
A firewall rule can off course save you if you are under attack but it is not a sullotion the the problem that data is miss interpreted and the system reboots as a result.

Please do your homework: Confirm or Defer the CVE so that we may rest or step up and protect our selves in the meantime while we wait for a patch.

Did you read my post entirely? A simple firewall stops it. Why don't you have it?

Let me think......... FASTPATH!

Did you read my post entirely? A simple firewall stops it. Why don't you have it?

Let me think......... FASTPATH!

Fastpath is only for FORWARD and this firewall rule would be in INPUT.

i'am experiencing random reboot on CCR1072 for about last 3 months, we have tickets and it's not solved yet.
We already tested with 3 routers with same series and Yes we have ipv6 enabled.

thx

thx

thx for what? did you read the above and apply what is being suggested? (an input firewall for ipv6)

thx

thx for what? did you read the above and apply what is being suggested? (an input firewall for ipv6)

Yes i already apply it

[buset@MikroTik-CORE-CBR] > /ipv6 firewall filter print where chain=input
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; drop invalids
chain=input action=drop connection-state=invalid

1 chain=input action=drop protocol=etherip log=yes log-prefix="input-prot-97-drop-ipv6"

2 ;;; allow established & related
chain=input action=accept connection-state=established log=no log-prefix="input-ipv6-related"

3 chain=input action=accept connection-state=related

4 ;;; allow icmp
chain=input action=accept protocol=icmpv6

5 ;;; Allow BGP
chain=input action=accept protocol=tcp dst-port=179

6 ;;; Allow MNTP
chain=input action=accept protocol=udp dst-port=5678

7 chain=input action=drop protocol=udp

8 X ;;; Allow from PSN-NET
chain=input action=accept src-address-list=PSN-NET-IPV6 log=no log-prefix=""

9 ;;; drop any
chain=input action=drop log=no log-prefix="input-ipv6-drop-any-"


And the router still having frequent reboot.

Yes i already apply it

And the router still having frequent reboot.

So you know it is not caused by this particular problem.
Then why do you add your comment to this topic? That is just useless.

You should rather focus on the problem you have at hand.

Dear all, just flagging that this vuln still shows as affecting the most recent version v7.14.2 via the json query:
Assuming is fixed, which version was this fixed in?

As NVD would need to add the versionEndIncluding field.

We were not able to reproduce this issue in 6.47.10/6.48.5 versions. There have been other IPv6 related fixes since then, for example, https://blog.mikrotik.com/software/cve- ... stion.html
It is a false positive.