MikroTik

!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);

Could you give some more info about the exploitability of this?

*) lte - fixed modem not receiving IP configuration when roaming (introduced in v6.45);

*) ike2 - fixed phase 1 rekeying (introduced in v6.45);

RouterOS version 6.45.7 has been released in public "stable" channel!
!) package - accept only packages with original filenames (CVE-2019-3976);
!) package - improved package signature verification (CVE-2019-3977);
!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);

Can`t upgrade to 6.45.7, not enough space to upgrade

how to upgrade?

"Simply disabling Winbox mitigates all of these attacks." - i couldn't agree more with this approach.
i understand that winbox was a key for many happy current RouterOS users to get acquainted with networking, as for many the CLI still kind of scary, and it is still doing it.
on the other hand, it is hard (if not impossible) to keep all these management interfaces (CLI, webfig, winbox, API) consistent and trouble-free. winbox is a great example for lacking behind in new features. i notoriously disable winbox on each unboxed device, i kept doing this since i laid my hands on the very first RouterOS device i encountered - i never liked to rely on windows, but that's just a personal preference.
I don't despise the existence of GUI tools, i just think that if there's something like winbox, it should rely on a 'standards-based' interface, like the API-SSL. or even based on SSH. i cannot imagine how hard it is to carry out such a drastic change to an existing ecosystem though.

At a high level, “messages” sent to the Winbox port can be routed to different binaries in RouterOS based on an array-based numbering scheme.

RouterOS without WinBox is like car without seats, it still runs, but it's not enjoyable ride. But it's clear now that it's not good idea to let it be exposed to whole world. I though that it shouldn't be a problem anymore, that MikroTik surely fixed it, to require robust authentication first before allowing to do anything else, but clearly not. Why was that DNS proxy functionality even there?

*) ike2 - fixed phase 1 rekeying (introduced in v6.45);

This is supposed to fix "ipsec,error Mikrotik: got fatal error: INVALID_SYNTAX"?

Works well on all my devices. Thanks Mikrotik for the update!

RouterOS version 6.45.7 has been released in public "stable" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 6.45.7 (2019-Oct-24 08:44):

MAJOR CHANGES IN v6.45.7:
----------------------
!) lora - added support for LoRaWAN low-power wide-area network technology for MIPSBE, MMIPS and ARM;
!) package - accept only packages with original filenames (CVE-2019-3976);
!) package - improved package signature verification (CVE-2019-3977);
!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);
----------------------

Changes in this release:

*) capsman - fixed frequency setting requiring multiple frequencies;
*) capsman - fixed newline character missing on some logging messages;
*) conntrack - properly start manually enabled connection tracking;
*) crs312 - fixed combo SFP port toggling (introduced in v6.44.5);
*) crs3xx - correctly display link rate when 10/100/1000BASE-T SFP modules are used in SFP+ interfaces;
*) crs3xx - fixed management access when using switch rule "new-vlan-priority" property;
*) export - fixed "bootp-support" parameter export;
*) ike2 - fixed phase 1 rekeying (introduced in v6.45);
*) led - fixed default LED configuration for RBLHG5nD;
*) lte - fixed modem not receiving IP configuration when roaming (introduced in v6.45);
*) radius - fixed open socket leak when invalid packet is received (introduced in v6.44);
*) sfp - fixed "sfp-rx-power" value for some transceivers;
*) snmp - improved reliability on SNMP service packet validation;
*) system - improved system stability for devices with AR9342 SoC;
*) winbox - show SFP tab for QSFP interfaces;
*) wireless - added "canada2" regulatory domain information;
*) wireless - improved stability when setting fixed primary and secondary channels on RB4011iGS+5HacQ2HnD-IN;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after some problem has appeared on device

Please keep this forum topic strictly related to this particular RouterOS release.

RouterOS without WinBox is like car without seats, it still runs, but it's not enjoyable ride. But it's clear now that it's not good idea to let it be exposed to whole world. I though that it shouldn't be a problem anymore, that MikroTik surely fixed it, to require robust authentication first before allowing to do anything else, but clearly not. Why was that DNS proxy functionality even there?

+10,000
Could not agree more

If I dont use winbox externally and I change the default port to something else, where is the risk from this latest vulnerability?
If I was to use winbox externally via VPN ( IKEv2), where is the risk?

No need to change winbox default port when using winbox internally -- risk is only from compromised workstations as noted below.

Being tied to Windows and specific client versions is just troublesome.

You may try downgrade first to an earlier stable version (e.g. 6.43.7) which takes less space on the device and then upgrade to 6.45.7

"Simply disabling Winbox mitigates all of these attacks." - i couldn't agree more with this approach.
i understand that winbox was a key for many happy current RouterOS users to get acquainted with networking, as for many the CLI still kind of scary, and it is still doing it.
on the other hand, it is hard (if not impossible) to keep all these management interfaces (CLI, webfig, winbox, API) consistent and trouble-free. winbox is a great example for lacking behind in new features. i notoriously disable winbox on each unboxed device, i kept doing this since i laid my hands on the very first RouterOS device i encountered - i never liked to rely on windows, but that's just a personal preference.
I don't despise the existence of GUI tools, i just think that if there's something like winbox, it should rely on a 'standards-based' interface, like the API-SSL. or even based on SSH. i cannot imagine how hard it is to carry out such a drastic change to an existing ecosystem though.

I couln't agree more.

Being tied to Windows and specific client versions is just troublesome. You don't see Cisco & Juniper putting much effort on GUI clients for their stuff (altough it exists).

When doing CAP upgrades via CAPsMAN, you have to manually upload needed packages to the place configured in /caps-man manager ... in particular properties package-path= and upgrade-policy= (that's a directory on CAPsMAN device itself, I don't know if it's possible to set it to some external resource). CAP won't search for upgrade packages on usual internet sources.

!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);

Could you give some more info about the exploitability of this? Are all situations where RouterOS parses a DNS packet vulnerable? Eg router used in typical setup - DNS server for LAN and sends queries to the internet (allow-remote-requests=yes) and router used only for local DNS (allow-remote-requests=no)?

Why are some points (hAP AC + HEX poe) updated without any problems, while others (RB951G+ hEX/RB3011) write that they can't find the file?

mkx
The mentioned devices are not all the same architecture: hAP AC and hEX PoE are both MIPSBE, so it is RB951G, but hEX (the current one - RB750Gr3) is MMIPS and RB3011 is ARM. All in all that's 3 distinct sets of files that you have to provide.

Guys, please stop it. There is no Mikrotik without a Winbox. Web interface, though comparable in funcitonality, is still not there. Kill Winbox and I am done with MT.

my point was merely to kill the "winbox protocol" and rather move the communication stack of the "well known and beloved" GUI tool over API or SSH. the convenient point-and-click thingie could remain there forever in unchanged visual format, given the large and loyal user base.

if it is documented - like SSH and API are - others can build similar GUI tools for different operating systems, and you would not need to rely on emulation/virtual machines just to have access to your device from a non windows environment. the protocol winbox uses is basically a black box, researchers are reverse engineering it with more or less success.

jacekes Should be fixed now.

Sunlight, flameproof Please send supout.rif file to support@mikrotik.com

maryaadmins Check if addresses are not given out by the Cisco router. In most cases, your described issue is caused by another DHCP server in your network.

When will be fixed that Ipsec tunnels hung up?

When will be fixed that Ipsec tunnels hung up?

Can you be more verbose regarding what you refer to? 6.45.4 is a factory-only release, and all your other posts refer to BGP. IPsec is important for me so I am really interested in the details.

Other than that, have you sent the related supout.rif to support@mikrotik.com? Developers cannot resolve an issue they cannot reproduce.

after deeper monitoring i became to conclusion that BGP failure coming from Ipsec Hung up. When its happens next time I ll sent suppout.rif

after deeper monitoring i became to conclusion that BGP failure coming from Ipsec Hung up. When its happens next time I ll sent suppout.rif

That statement gives no details regarding what actually happens and what IPsec configuration you use - there are many possible variants of IPsec configuration and only some of them may be affected. You may want to open a dedicated topic and post a network diagram and anonymized configuration exports there.

I use Gre over ipsec with BGP routing.

Sunlight, flameproof Please send supout.rif file to support@mikrotik.com

/interface wireless security-profiles
set [ find default=yes ] disable-pmkid=yes eap-methods="" \
    supplicant-identity=MikroTik
add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" \
    management-protection=allowed mode=dynamic-keys name=Net \
    supplicant-identity="" wpa2-pre-shared-key=********
add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" \
    management-protection=allowed mode=dynamic-keys name=Smart \
    supplicant-identity="" wpa2-pre-shared-key=********
/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n/ac channel-width=\
    20/40/80/160mhz-Ceeeeeee disabled=no frequency-mode=superchannel \
    installation=indoor mac-address=76:4D:28:5A:9C:74 mode=ap-bridge name=\
    wlan1-net2-5G security-profile=Net ssid=Net_5G \
    wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled
set [ find default-name=wlan2 ] band=2ghz-b/g/n disabled=no installation=\
    indoor mac-address=76:4D:28:5A:9C:76 mode=ap-bridge name=wlan2-net1-2G \
    security-profile=Net ssid=Net tx-power=30 tx-power-mode=\
    all-rates-fixed wireless-protocol=802.11 wmm-support=enabled wps-mode=\
    disabled
add keepalive-frames=disabled mac-address=76:4D:28:5A:9C:75 master-interface=\
    wlan1-net2-5G multicast-buffering=disabled name=wlan1-net1-5G \
    security-profile=Net ssid=Net wds-cost-range=0 wds-default-cost=0 \
    wmm-support=enabled wps-mode=disabled
add disabled=no keepalive-frames=disabled mac-address=86:25:19:1A:1E:82 \
    master-interface=wlan2-net1-2G multicast-buffering=disabled name=\
    wlan2-smart-2G security-profile=Smart ssid=Smart \
    wds-cost-range=0 wds-default-cost=0 wmm-support=enabled wps-mode=disabled

Guys, please stop it. There is no Mikrotik without a Winbox. Web interface, though comparable in funcitonality, is still not there. Kill Winbox and I am done with MT.

don't want to turn the thread into a flame war. i agree, a lot of people need GUI, a lot of people love the look&feel of winbox, sure thing. not like i'd have the power or the will to take away your tools. in some parts winbox app is directly responsible for the popularity of RouterOS because it made the 'mystic networking stuff' accessible for the masses.
my point was merely to kill the "winbox protocol" and rather move the communication stack of the "well known and beloved" GUI tool over API or SSH. the convenient point-and-click thingie could remain there forever in unchanged visual format, given the large and loyal user base.

if it is documented - like SSH and API are - others can build similar GUI tools for different operating systems, and you would not need to rely on emulation/virtual machines just to have access to your device from a non windows environment. the protocol winbox uses is basically a black box, researchers are reverse engineering it with more or less success.

but i'm just stating my opinion, that's all.

On 6.45.7:
Most probably a bug in new version.

On 6.45.7:
Most probably a bug in new version.

What architecture? I've just tested that on my arm (hAP ac²) and there is no issue:

[me@MyTik] > system script print where name~"test"
Flags: I - invalid
0 name="test" owner="me" policy=read,write,test dont-require-permissions=no last-started=nov/05/2019 18:10:19 run-count=3
source=local dnsServer 9.9.9.9 ; put [resolve nationalgeographic.com server=$dnsServer]
[me@MyTik] > system script run test
23.60.72.183

I even ran the script while logged as different user than the script owner, still doing fine.

Had an issue upgrading from 6.43.12 directly to 6.45.7 on a single RB1100AHx4 - the information in /ip ipsec peer wasn't properly split into the /ip ipsec peer and /ip ipsec identity parts, the latter was missing completely. In 6.43.12, auth-method pre-shared-key and pre-shared-key-xauth were used together with exchange-mode=ike2. Upgrade of another RB1100AHx4 from 6.43.16 didn't suffer from this issue, neither did an upgrade of CHRs from 6.43.7, 6.43.8 and 6.43.16.

Most likely, that's the reason you were left with an incomplete setup after upgrading.
...
As we have hundreds of devices with this setting, we cannot upgrade from 6.43.16 without destroying our ipsec setup.

RouterOS version 6.45.7 has been released in public "stable" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 6.45.7 (2019-Oct-24 08:44):

MAJOR CHANGES IN v6.45.7:
----------------------
!) lora - added support for LoRaWAN low-power wide-area network technology for MIPSBE, MMIPS and ARM;
!) package - accept only packages with original filenames (CVE-2019-3976);
!) package - improved package signature verification (CVE-2019-3977);
!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);
----------------------

Changes in this release:

*) capsman - fixed frequency setting requiring multiple frequencies;
*) capsman - fixed newline character missing on some logging messages;
*) conntrack - properly start manually enabled connection tracking;
*) crs312 - fixed combo SFP port toggling (introduced in v6.44.5);
*) crs3xx - correctly display link rate when 10/100/1000BASE-T SFP modules are used in SFP+ interfaces;
*) crs3xx - fixed management access when using switch rule "new-vlan-priority" property;
*) export - fixed "bootp-support" parameter export;
*) ike2 - fixed phase 1 rekeying (introduced in v6.45);
*) led - fixed default LED configuration for RBLHG5nD;
*) lte - fixed modem not receiving IP configuration when roaming (introduced in v6.45);
*) radius - fixed open socket leak when invalid packet is received (introduced in v6.44);
*) sfp - fixed "sfp-rx-power" value for some transceivers;
*) snmp - improved reliability on SNMP service packet validation;
*) system - improved system stability for devices with AR9342 SoC;
*) winbox - show SFP tab for QSFP interfaces;
*) wireless - added "canada2" regulatory domain information;
*) wireless - improved stability when setting fixed primary and secondary channels on RB4011iGS+5HacQ2HnD-IN;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after some problem has appeared on device

Please keep this forum topic strictly related to this particular RouterOS release.

On 6.43.11:
I have a script containing the following command:

Code: Select all

:resolve $hostname server=$NS

I set "read, write, test" permission on this script, run without error

On 6.45.7:
When the same script run into the command

Code: Select all

:resolve $hostname server=$NS"

it caused the "not enough permissions (9)" error.
When I remove the portion "server=$NS", it runs normally.
I tried to remove all permission setting, add all permission setting, and even added "Don't Require Permissions", all in vain.

Most probably a bug in new version.

in 6.45.7，the “resolve” command can't work with AAAA records，it returns “not enough permissions (9)”，please fix it

:put [:resolve ipv6.google.com]
2607:f8b0:4004:810::200e

:put [:resolve ipv6.google.com]
not enough permissions (9)

When will be fixed that Ipsec tunnels hung up? It starts from 6.45.4 and continues. Helps only clear connection.

When will be fixed that Ipsec tunnels hung up? It starts from 6.45.4 and continues. Helps only clear connection.

Same thing here on CCR1072. Updated to 6.45.7 (both routerboard and ROS), and it happened after 20 hours. The IPsec tunnel was still up, but no traffic was passing. The solution was to hit "Kill Connections" on the Active Peers tab. The IPsec tunnel is Aes-128-cbc encrypted (IKE2 exchange mode), with ecp384 DH group. Previously happened on 6.45.3 as well.

Please spawn a dedicated topic and provide the complete IPsec configuration there (proposals, peer profiles, identities - everything may matter, just use hide-sensitive while exporting to keep your keys secret, and obfuscate the public IP addresses following the hint in my automatic signature below). If the other peer is not a Mikrotik, describe what it is and provide its configuration too if you have access to it. 20 hours is a weird time interval, as it doesn't match any of the default lifetimes - the phase 1 lifetime is typically 24h whereas the phase 2 lifetime is typically 30m. So if it is not some memory leak, it looks like an unsuccessful phase2 renegotiation, which is an issue which existed in IKEv2 in early 6.43 versions if I remember well. It was easy to spot if you had access to both ends - the ephemeral enc-key values of the installed-sa with the same spi value were different between the peers. If you lose access to the remote peer once this happens and can afford it, just give it 30 minutes and see whether it eventually recovers. Back then, it was happening randomly, not at all peers at the same time.

We are usually noticing this after a SW upgrade and/or outage, that IPsec tunnels are not recovering, or going down after a couple hours of operation.

Hi, I did an RB upgrade to the 6.45.7 version and from that moment the DDNS Cloud, to reach the RB remotely, no longer works. The public address is not tracked.
Having a dynamic public ip, I need to solve the problem. How can I do?
Thanks

[ak@RO-20] >/ip cloud export terse
# nov/14/2019 01:49:13 by RouterOS 6.45.7
# model = RouterBOARD 750G r3
/ip cloud set ddns-enabled=yes update-time=no

[ak@RO-20] >/ip cloud print
          ddns-enabled: yes
  ddns-update-interval: none
           update-time: no
                status: updating...

firewall not work.
the computer is connected to ether 2 (IP: 192.168.1.100), the laptop is connected to ether 3 ((IP: 192.168.1.251).

disabling hardware-accelerated forwarding.

I turned off acceleration forwarding. And i am use Firewall (see pic).

I turned off acceleration forwarding. And i am use Firewall (see pic).

/interface bridge port set [find] hw=no
is the way to disable hardware-accelerated forwarding (accelerated by the switch chip, so the frames don't even get to the CPU so that it could push them through the ip firewall).

But first of all, you should prefer routing when policing the communication among devices on your LAN, and second, this is definitely nothing specific to 6.45.7.

Today morning my CCR1009 suddenly stopped responding to snmp requests.
Seems that all snmp related settings are gone. No changes were made recently.
An export of /snmp never finishes.

On 6.43.11:
I have a script containing the following command:

Code: Select all

:resolve $hostname server=$NS

I set "read, write, test" permission on this script, run without error

On 6.45.7:
When the same script run into the command

Code: Select all

:resolve $hostname server=$NS"

it caused the "not enough permissions (9)" error.
When I remove the portion "server=$NS", it runs normally.
I tried to remove all permission setting, add all permission setting, and even added "Don't Require Permissions", all in vain.

Most probably a bug in new version.

This is the same issue as this:

in 6.45.7，the “resolve” command can't work with AAAA records，it returns “not enough permissions (9)”，please fix it

Which I am also seeing:
CHR running v6.45.6:

Code: Select all

:put [:resolve ipv6.google.com]
2607:f8b0:4004:810::200e

CHR running 6.45.7:

Code: Select all

:put [:resolve ipv6.google.com]
not enough permissions (9)

This also happens on arm arch. where just before an upgrade it worked.

On 6.43.11:
I have a script containing the following command:

Code: Select all

:resolve $hostname server=$NS

I set "read, write, test" permission on this script, run without error

On 6.45.7:
When the same script run into the command

Code: Select all

:resolve $hostname server=$NS"

it caused the "not enough permissions (9)" error.
When I remove the portion "server=$NS", it runs normally.
I tried to remove all permission setting, add all permission setting, and even added "Don't Require Permissions", all in vain.

Most probably a bug in new version.

This is the same issue as this:

in 6.45.7，the “resolve” command can't work with AAAA records，it returns “not enough permissions (9)”，please fix it

Which I am also seeing:
CHR running v6.45.6:

Code: Select all

:put [:resolve ipv6.google.com]
2607:f8b0:4004:810::200e

CHR running 6.45.7:

Code: Select all

:put [:resolve ipv6.google.com]
not enough permissions (9)

This also happens on arm arch. where just before an upgrade it worked.

Is the hotspot still broken on anything over 6.44.6?

RB1100AH4x 6.45.7

nothing special in my configuration. just few firewall rules.

"Router was rebooted after proper shutdown"
Happens now 2 times after 7 and 21 days of running

Really long uptimes i only got with the 6.44.xx

-faxxe

Is there any known reason why (what looks like) all NAT stops working in 6.45.7 after a few hours?

Where do I even start yo debug this?