For those of you who don't follow AUSNOG... "critical vulnerability" for Mikrotik devices running IPv6 (even firewalled) that you should know about: https://forum.mikrotik.com/viewtopic.php?t=147076 Mikrotik have acknowledged it: https://forum.mikrotik.com/viewtopic.php?f=2&t=147048#p723696 Twitter thread from the person who discovered it: https://twitter.com/maznu/status/1110910688623513601 No current fix. Shane
There may be a fix on the horizon: What's new in 6.45beta22 (2019-Mar-29 08:37): Changes in this release: !) ipv6 - fixed soft lockup when forwarding IPv6 packets (CVE-2018-19299); !) ipv6 - fixed soft lockup when processing large IPv6 Neighbor table (CVE-2018-19298); https://mikrotik.com/download/changelogs/testing-release-tree -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Shane Clay Sent: Friday, 29 March 2019 12:37 PM To: Public@talk.mikrotik.com.au Subject: [MT-AU Public] UKNOF 43 CVE For those of you who don't follow AUSNOG... "critical vulnerability" for Mikrotik devices running IPv6 (even firewalled) that you should know about: https://forum.mikrotik.com/viewtopic.php?t=147076 Mikrotik have acknowledged it: https://forum.mikrotik.com/viewtopic.php?f=2&t=147048#p723696 Twitter thread from the person who discovered it: https://twitter.com/maznu/status/1110910688623513601 No current fix. Shane _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Unfortunately this apparently fixes 2x softlock issues, but not a memory leak that results in a reboot of the device. You can read from here on to see more information: https://forum.mikrotik.com/viewtopic.php?f=2&t=147048#p723977 Regards, Philip Loenneker | Network Engineer | TasmaNet -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Shane Clay Sent: Friday, 29 March 2019 10:07 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE There may be a fix on the horizon: What's new in 6.45beta22 (2019-Mar-29 08:37): Changes in this release: !) ipv6 - fixed soft lockup when forwarding IPv6 packets (CVE-2018-19299); !) ipv6 - fixed soft lockup when processing large IPv6 Neighbor table (CVE-2018-19298); https://mikrotik.com/download/changelogs/testing-release-tree -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Shane Clay Sent: Friday, 29 March 2019 12:37 PM To: Public@talk.mikrotik.com.au Subject: [MT-AU Public] UKNOF 43 CVE For those of you who don't follow AUSNOG... "critical vulnerability" for Mikrotik devices running IPv6 (even firewalled) that you should know about: https://forum.mikrotik.com/viewtopic.php?t=147076 Mikrotik have acknowledged it: https://forum.mikrotik.com/viewtopic.php?f=2&t=147048#p723696 Twitter thread from the person who discovered it: https://twitter.com/maznu/status/1110910688623513601 No current fix. Shane _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
For all who are not watching this thread closely, MikroTik have released an effective patch for this issue, albeit currently only in beta chain: 6.45beta23 They say that there is some more optimisation to be done for routers with low RAM before it will be released into long term and stable versions. No firm date on when that might happen. For low memory capacity routers (< 100MB) or in cases where upgrade is not feasible, firewall rules to limit new connection rates will help to defeat an attack using the exploit: /ipv6 firewall filter add action=drop chain=forward connection-mark=drop connection-state=new /ipv6 firewall mangle add action=accept chain=prerouting connection-state=new dst-address=\ [your:network::/64] limit=2,5:packet add action=mark-connection chain=prerouting connection-state=new dst-address=\ [your:network::/64] new-connection-mark=drop passthrough=yes It is important to note that this problem affects routing function of ipv6, so packets with final destination of any host forwarded by a router will make that router vulnerable (i.e. input chain is no use for above rules) FWIW, the MikroTik spokesman handling this case has acknowledged that they made a mistake in filing the original CVE/s and should have addressed the problem/s sooner. Hopefully this event will encourage them to adjust their handling of such reports better in future :-j Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Shane Clay Sent: Friday, 29 March 2019 1:07 PM To: Public@talk.mikrotik.com.au Subject: [MT-AU Public] UKNOF 43 CVE
For those of you who don't follow AUSNOG... "critical vulnerability" for Mikrotik devices running IPv6 (even firewalled) that you should know about:
https://forum.mikrotik.com/viewtopic.php?t=147076
Mikrotik have acknowledged it: https://forum.mikrotik.com/viewtopic.php?f=2&t=147048#p723696
Twitter thread from the person who discovered it: https://twitter.com/maznu/status/1110910688623513601
No current fix.
Shane _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Wed, 2019-04-03 at 12:41 +1100, Mike Everest wrote:
MikroTik have released an effective patch for this issue [...] It is important to note that this problem affects routing function of ipv6, so packets with final destination of any host forwarded by a router will make that router vulnerable (i.e. input chain is no use for above rules)
Sorry, Mike, I don't understand that paragraph at all. Can you clarify, please? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB
On 3/4/19 1:29 pm, Karl Auer wrote:
MikroTik have released an effective patch for this issue [...] It is important to note that this problem affects routing function of ipv6, so packets with final destination of any host forwarded by a router will make that router vulnerable (i.e. input chain is no use for above rules) Sorry, Mike, I don't understand that paragraph at all. Can you clarify,
On Wed, 2019-04-03 at 12:41 +1100, Mike Everest wrote: please?
Regards, K.
Mike E is saying that simply seeing a ipv6 packet is a problem. I have no idea if he is correct because I've not seen the details behind the issue. Mike
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike O'Connor Sent: Wednesday, 3 April 2019 2:32 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au>; Karl Auer <kauer@nullarbor.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
On 3/4/19 1:29 pm, Karl Auer wrote:
On Wed, 2019-04-03 at 12:41 +1100, Mike Everest wrote:
MikroTik have released an effective patch for this issue [...] It is important to note that this problem affects routing function of ipv6, so packets with final destination of any host forwarded by a router will make that router vulnerable (i.e. input chain is no use for above rules) Sorry, Mike, I don't understand that paragraph at all. Can you clarify, please?
Regards, K.
Mike E is saying that simply seeing a ipv6 packet is a problem.
I have no idea if he is correct because I've not seen the details behind
Mike, Karl, Yes, that's an accurate translation of my clumsily worded statement! :-} To clarify further, the particularly nasty issue (the one from this recent discussion that has caused the most angst) is related to the ipv6 routing engine. Essentially, an attack on a specific router can be made by sending 'specially crafted' IPv6 packet to any IPv6 host on any network via the target router. So such malicious packets could have destination address of another router server, host, client on your network. The structure/content of such malicious packets are not matchable by any of the available packet attributes of MikroTik firewall, and therefore, the only way to effectively limit excess dodgy packets is to limit ALL ipv6 connections to a limited rate. Typically, attacks that target a specific device by sending packets with destination address OF THAT device which can be mitigated using input chain of firewall. For reasons outlined above, input chain can not be used for this case. Therfore, until the bugfix/longterm and stable versions include this recent fix, core routers processing significant (more than 2 new connections per sec, burst of 5) we recommend to run the 6.45beta23 software release, and firewall filters for all other routers. Of course if you do not really *need* ipv6 right now, it is also worth considering to just temporarily turn off IPv6 in the interim (by disabling IPv6 package, disable all public ipv6 addresses, or just remove network advertisement from your BGP) For us, ipv6 is mostly experimental since it is only inside our WAN and across one upstream peer, so we'll be disabling for a couple of weeks at least. <sigh> I suppose IPv6 can still be considered 'new' for most of us (even though it *shouldn't* be!) and that this sort of event can be welcomed as just another step toward efficient and effective universal IPv6 for everyone. I suspect that it won't be the last time it happens (and not just MikroTik I'm sure ;) and we should all be thankful for guys like the fellow who discovered this one and made some concerted effort to make sure it was addressed! Hope it clarifies the situation better :-} Cheers! Mike. the
issue.
Mike
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike O'Connor Sent: Wednesday, 3 April 2019 2:32 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au>; Karl Auer <kauer@nullarbor.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
On 3/4/19 1:29 pm, Karl Auer wrote:
On Wed, 2019-04-03 at 12:41 +1100, Mike Everest wrote:
MikroTik have released an effective patch for this issue [...] It is important to note that this problem affects routing function of ipv6, so packets with final destination of any host forwarded by a router will make that router vulnerable (i.e. input chain is no use for above rules) Sorry, Mike, I don't understand that paragraph at all. Can you clarify, please?
Regards, K.
Mike E is saying that simply seeing a ipv6 packet is a problem.
I have no idea if he is correct because I've not seen the details behind
Just to be clear - if you only disable IPv6 addresses and BGP peers, but leave the IPv6 package enabled, you are still left with link-local (fe80::) addresses and the router can still be the victim of an attack. It is reduced scope to only layer 2 connections (you can't get attacked from anything that would have to be routed to reach you), however it is still a risk. Regards, Philip Loenneker | Network Engineer | TasmaNet -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Wednesday, 3 April 2019 3:05 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au>; 'Karl Auer' <kauer@nullarbor.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE Mike, Karl, Yes, that's an accurate translation of my clumsily worded statement! :-} To clarify further, the particularly nasty issue (the one from this recent discussion that has caused the most angst) is related to the ipv6 routing engine. Essentially, an attack on a specific router can be made by sending 'specially crafted' IPv6 packet to any IPv6 host on any network via the target router. So such malicious packets could have destination address of another router server, host, client on your network. The structure/content of such malicious packets are not matchable by any of the available packet attributes of MikroTik firewall, and therefore, the only way to effectively limit excess dodgy packets is to limit ALL ipv6 connections to a limited rate. Typically, attacks that target a specific device by sending packets with destination address OF THAT device which can be mitigated using input chain of firewall. For reasons outlined above, input chain can not be used for this case. Therfore, until the bugfix/longterm and stable versions include this recent fix, core routers processing significant (more than 2 new connections per sec, burst of 5) we recommend to run the 6.45beta23 software release, and firewall filters for all other routers. Of course if you do not really *need* ipv6 right now, it is also worth considering to just temporarily turn off IPv6 in the interim (by disabling IPv6 package, disable all public ipv6 addresses, or just remove network advertisement from your BGP) For us, ipv6 is mostly experimental since it is only inside our WAN and across one upstream peer, so we'll be disabling for a couple of weeks at least. <sigh> I suppose IPv6 can still be considered 'new' for most of us (even though it *shouldn't* be!) and that this sort of event can be welcomed as just another step toward efficient and effective universal IPv6 for everyone. I suspect that it won't be the last time it happens (and not just MikroTik I'm sure ;) and we should all be thankful for guys like the fellow who discovered this one and made some concerted effort to make sure it was addressed! Hope it clarifies the situation better :-} Cheers! Mike. the
issue.
Mike
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Philip Loenneker Sent: Wednesday, 3 April 2019 3:30 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au>; 'Karl Auer' <kauer@nullarbor.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
Just to be clear - if you only disable IPv6 addresses and BGP peers, but leave the IPv6 package enabled, you are still left with link-local (fe80::) addresses and the router can still be the victim of an attack. It is reduced scope to only layer 2 connections (you can't get attacked from anything that would have to be routed to reach you), however it is still a risk.
Regards, Philip Loenneker | Network Engineer | TasmaNet
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Wednesday, 3 April 2019 3:05 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au>; 'Karl Auer' <kauer@nullarbor.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
Mike, Karl,
Yes, that's an accurate translation of my clumsily worded statement! :-}
To clarify further, the particularly nasty issue (the one from this recent discussion that has caused the most angst) is related to the ipv6 routing engine. Essentially, an attack on a specific router can be made by sending 'specially crafted' IPv6 packet to any IPv6 host on any network via the target router. So such malicious packets could have destination address of another router server, host, client on your network. The structure/content of such malicious packets are not matchable by any of the available packet attributes of MikroTik firewall, and therefore, the only way to effectively limit excess dodgy packets is to limit ALL ipv6 connections to a limited rate.
Typically, attacks that target a specific device by sending packets with destination address OF THAT device which can be mitigated using input chain of firewall. For reasons outlined above, input chain can not be used for
Fair call! - agreed: disable the package if you can't trust anyone (including customers ;) who have link local ipv6 access ;) Cheers,.. Mike. this
case.
Therfore, until the bugfix/longterm and stable versions include this recent fix, core routers processing significant (more than 2 new connections per sec, burst of 5) we recommend to run the 6.45beta23 software release, and firewall filters for all other routers.
Of course if you do not really *need* ipv6 right now, it is also worth considering to just temporarily turn off IPv6 in the interim (by disabling IPv6 package, disable all public ipv6 addresses, or just remove network advertisement from your BGP)
For us, ipv6 is mostly experimental since it is only inside our WAN and across one upstream peer, so we'll be disabling for a couple of weeks at least.
<sigh>
I suppose IPv6 can still be considered 'new' for most of us (even though it *shouldn't* be!) and that this sort of event can be welcomed as just another step toward efficient and effective universal IPv6 for everyone. I suspect that it won't be the last time it happens (and not just MikroTik I'm sure ;) and we should all be thankful for guys like the fellow who discovered this one and made some concerted effort to make sure it was addressed!
Hope it clarifies the situation better :-}
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike O'Connor Sent: Wednesday, 3 April 2019 2:32 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au>; Karl Auer <kauer@nullarbor.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
On 3/4/19 1:29 pm, Karl Auer wrote:
On Wed, 2019-04-03 at 12:41 +1100, Mike Everest wrote:
MikroTik have released an effective patch for this issue [...] It is important to note that this problem affects routing function of ipv6, so packets with final destination of any host forwarded by a router will make that router vulnerable (i.e. input chain is no use for above rules) Sorry, Mike, I don't understand that paragraph at all. Can you clarify, please?
Regards, K.
Mike E is saying that simply seeing a ipv6 packet is a problem.
I have no idea if he is correct because I've not seen the details behind the issue.
Mike
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Further information and updates here: https://shop.duxtel.com.au/article_info.php?articles_id=89 Cheers,..
Thanks Mike, great summary, much appreciated. Only problem is to disable IPV6 package means a reboot ☹ Regards Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Thursday, 4 April 2019 2:12 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE Further information and updates here: https://shop.duxtel.com.au/article_info.php?articles_id=89 Cheers,.. _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Yes, sad but true :-(
From our part, I have opted to add the firewall rules since IPv6 on our network is purely 'experimental' and we don't even have any published services running yet (web sites were next on the list ;)
Once the fix/patch makes it to bugfix chain, then we'll update and save reboot for then. Cheers, Mike. ------------------------------------------------------------------------------------ Why Choose DuxTel for all your MikroTik needs? 10 good reasons: http://duxtel.com/why_duxtel ------------------------------------------------------------------------------------ Follow our tweets for news and updates: http://twitter.com/duxtel
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Thursday, 4 April 2019 2:45 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
Thanks Mike, great summary, much appreciated.
Only problem is to disable IPV6 package means a reboot ☹
Regards Paul
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Thursday, 4 April 2019 2:12 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
Further information and updates here: https://shop.duxtel.com.au/article_info.php?articles_id=89
Cheers,..
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Thu, 2019-04-04 at 14:11 +1100, Mike Everest wrote:
Further information and updates here: https://shop.duxtel.com.au/article_info.php?articles_id=89
Hullo Mike You write in that post: "It is important to note that this problem affects routing function of ipv6, so packets with final destination of any host forwarded by a router will make that router vulnerable (i.e. input chain is no use for above rules)*" Your clarification does, well, clarify this, but I suggest the following wording of the above para instead: "It is important to note that this problem affects the IPv6 routing function of MikroTik routers. Any MikroTik router that is forwarding IPv6 packets is vulnerable (i.e. using the above rules in an input chain will not help)*" Assuming I've understood correctly, of course. If not, could you clarify the clarification please :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB
Hi Karl, Your alternative wording is accurate in the context of the intended point! :-) However, I chose my version specifically to also try to make it clear that 'attack' packets do not necessarily carry the ip address of the target as destination (or source for that matter) - general term 'forwarding' does imply that, yes, but I wanted to go beyond just implication and make it absolutely clear. We could begin a discussion from here about semantics and technical meaning of 'forward' in this context (to which I am sure I will largely agree with you ;-) but I think it is a technical term that may not always be completely obvious to everyone on this list :-} I am very open to other versions of that sentence that you (or others) might consider more sensible! :-) Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Thursday, 4 April 2019 4:12 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
On Thu, 2019-04-04 at 14:11 +1100, Mike Everest wrote:
Further information and updates here: https://shop.duxtel.com.au/article_info.php?articles_id=89
Hullo Mike
You write in that post:
"It is important to note that this problem affects routing function of ipv6, so packets with final destination of any host forwarded by a router will make that router vulnerable (i.e. input chain is no use for above rules)*"
Your clarification does, well, clarify this, but I suggest the following wording of the above para instead:
"It is important to note that this problem affects the IPv6 routing function of MikroTik routers. Any MikroTik router that is forwarding IPv6 packets is vulnerable (i.e. using the above rules in an input chain will not help)*"
Assuming I've understood correctly, of course. If not, could you clarify the clarification please :-)
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Thu, 2019-04-04 at 16:40 +1100, Mike Everest wrote:
We could begin a discussion from here about semantics and technical meaning of 'forward' in this context
Oh lordy, please, no! :-) I'm sure anyone for whom it is important will figure it out quickly enough. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB
Apologies to any who consider it noise :-} MikroTik have released patches addressing IPv6 memory depletion bug in bugfix/long-term and stable release channels. Our recommendation is to upgrade all routers with IPv6 enabled (whether configured or not) to v6.43.14 (bugfix) as soon as possible. Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Thursday, 4 April 2019 2:12 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
Further information and updates here: https://shop.duxtel.com.au/article_info.php?articles_id=89
Cheers,..
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Great news, thanks for the update Mike. Regards Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Friday, 5 April 2019 10:12 AM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE Apologies to any who consider it noise :-} MikroTik have released patches addressing IPv6 memory depletion bug in bugfix/long-term and stable release channels. Our recommendation is to upgrade all routers with IPv6 enabled (whether configured or not) to v6.43.14 (bugfix) as soon as possible. Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Thursday, 4 April 2019 2:12 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
Further information and updates here: https://shop.duxtel.com.au/article_info.php?articles_id=89
Cheers,..
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Fri, 2019-04-05 at 10:11 +1100, Mike Everest wrote:
Apologies to any who consider it noise :-} MikroTik have released patches addressing IPv6 memory depletion bug in bugfix/long-term and stable release channels.
The abovementioned fix appears to address only CVE-2018-19298. So has anyone checked to see whether the patched ROS is now not vulnerable to CVE-2018-19299? Isalski says it is, but doesn't mention actual ROS versions. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556 Old fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D
Hi Karl, According to all official statements (and acknowledged by the reporting researcher) lastest builds on all release channels now address all (3) documented vulnerabilities. An earlier release (around April 2) did not include patch for CVE-2018-19298, which is probably the one referred in forum posts. Further along that thread, Isalski confirms corrected behaviour. Hope it helps ease concerns! :-} Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Wednesday, 10 April 2019 11:22 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
On Fri, 2019-04-05 at 10:11 +1100, Mike Everest wrote:
Apologies to any who consider it noise :-} MikroTik have released patches addressing IPv6 memory depletion bug in bugfix/long-term and stable release channels.
The abovementioned fix appears to address only CVE-2018-19298.
So has anyone checked to see whether the patched ROS is now not vulnerable to CVE-2018-19299? Isalski says it is, but doesn't mention actual ROS versions.
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
GPG fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556 Old fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Wed, 2019-04-10 at 11:32 +1000, Mike Everest wrote:
According to all official statements (and acknowledged by the reporting researcher) lastest builds on all release channels now address all (3) documented vulnerabilities.
So to be completely specific: 6.43.14 LTR (4 April) 6.44.2 Stable (4 April) 6.45beta23 (1 April) All seem to have the same three changes (among others): !) ipv6 - fixed soft lockup when forwarding IPv6 packets; !) ipv6 - fixed soft lockup when processing large IPv6 Neighbor table; *) ipv6 - adjust IPv6 route cache max size based on total RAM memory; 6.45beta23 (29 March)had only the first two. Oddly, NONE of them actually mention vulnerability identifiers. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556 Old fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D
Hi Karl, Yes - that is correct. You are right that no case IDs are mentioned, and I suspect that it is probably intentional on their (MikroTik) part for their usual unguessable reasons ;) The 6.45beta23 is the first released version that contains fixes for all reported IPv6 bug/vulnerability issues. The reason that the latter two (longterm/bugfix and stable channels) have the additional entry in changelog is because the beta version was still problematic for routers with limited RAM - thus stable and longterm have the added memory management solution to provide the workable patch for all router models. Hope it makes sense - even if it is only 'MikroTik sense' ;-) Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Wednesday, 10 April 2019 1:05 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
On Wed, 2019-04-10 at 11:32 +1000, Mike Everest wrote:
According to all official statements (and acknowledged by the reporting researcher) lastest builds on all release channels now address all (3) documented vulnerabilities.
So to be completely specific:
6.43.14 LTR (4 April) 6.44.2 Stable (4 April) 6.45beta23 (1 April)
All seem to have the same three changes (among others):
!) ipv6 - fixed soft lockup when forwarding IPv6 packets; !) ipv6 - fixed soft lockup when processing large IPv6 Neighbor table; *) ipv6 - adjust IPv6 route cache max size based on total RAM memory;
6.45beta23 (29 March)had only the first two.
Oddly, NONE of them actually mention vulnerability identifiers.
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
GPG fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556 Old fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Wed, 2019-04-10 at 14:04 +1000, Mike Everest wrote:
Hi Karl,
Yes - that is correct.
Thanks, After upgradingto latest stable, I have no IPv6 connectivity to the Internet, but I cannot conclusively say it was the upgrade :-) Would be interested to hear from people who have installed 6.44.2 stable who still have IPv6 over PPPoE (which is what I have via Internode) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556 Old fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D
Hi Karl, We have no v6 pppoe, but our edge routers have the latest bugfix version (6.43.14) and working fine (so far ;) On the bright side, I suppose you are safe from those attack vectors now :-j Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Wednesday, 10 April 2019 2:19 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
On Wed, 2019-04-10 at 14:04 +1000, Mike Everest wrote:
Hi Karl,
Yes - that is correct.
Thanks,
After upgradingto latest stable, I have no IPv6 connectivity to the Internet, but I cannot conclusively say it was the upgrade :-)
Would be interested to hear from people who have installed 6.44.2 stable who still have IPv6 over PPPoE (which is what I have via Internode)
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
GPG fingerprint: 887A DA07 4DCC EE76 B413 27D4 C638 4189 6CF0 D556 Old fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
ooooHHHHHH. This is goooooood.... *What's new in 6.45beta31 (2019-Apr-12 10:29):* * **MAJOR CHANGES IN v6.45:** **---------------------- ** **!) dot1x - added support for IEEE 802.1X Port-Based Network Access Control (CLI only) * Sorry for the noise... But have been waiting for this feature for a long time.. Cheers Greg,
participants (7)
-
greg -
Karl Auer -
Mike Everest -
Mike O'Connor -
Paul Julian -
Philip Loenneker -
Shane Clay