RouterOS version 6.45.7 has been released in public “stable” channel!
Before an upgrade:
Remember to make backup/export files before an upgrade and save them on another storage device;
Make sure the device will not lose power during upgrade process;
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.
!) 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)?
“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.
never the less, the package system related exploits would have been still dangerous, as DNS queries are easily manipulated (a DNSSEC aware resolver and DNSSEC signed zone for mikrotik.com would be a good way forward). thanks for the fixes in such a short time.
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?
Since when exists these vulnerabilities ? Or which versions affected ? v5.xx ? v6.xx ?
If I set max cache time to 0s… can it prevent the cache poisoning ?
If I set static resolver names… can it prevent the cache poisoning ?
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).
My hex Poe upgrade from 6.45.6 to 6.45.7, the avg processor CPU increases to 5% from 2% before. Librenms snmp has a very clear graph.
Edit: CPU became normal after 1 hour and 10 min. No idea what it was doing. Everything else looks normal at that time. No spike of traffic. Maybe recalculate address list or run some scripts after firmware upgrade?
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.
Sigh… who designed this braindead protocol that allows UNAUTHENTICATED USERS to invoke whatever binary they want?! Any programmer could see what a terrible idea this is. It seems the Winbox protocol needs to be scrapped and rebuilt with security in mind from day one rather than band-aid patches for vulnerability after vulnerability.
Yes. Winbox is a reason to use Mikrotik. Fast easy managment without IP setup is a big deal handling problems in the field. Every box needs filtering anyway …