RouterOS version 6.49.13 has been released in the "v6 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.49.13 (2024-Feb-05 15:39):
*) defconf - fixed firewall rule for IPv6 UDP traceroute;
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 a router is not working as suspected or after some problem has appeared on the device
Please keep this forum topic strictly related to this particular RouterOS release.
Re: v6.49.13 [stable] is released!
Please explain:
Why are v7 release topics renamed and used throughout 7.13.x patch releases (7.13.1, 7.13.2, etc.) but on v6 there is still a separate topic for each release. 6.49.12 (and before all 6.49.x) got its own topic and now 6.49.13.
Just want to understand.
Why are v7 release topics renamed and used throughout 7.13.x patch releases (7.13.1, 7.13.2, etc.) but on v6 there is still a separate topic for each release. 6.49.12 (and before all 6.49.x) got its own topic and now 6.49.13.
Just want to understand.
Re: v6.49.13 [stable] is released!
Also: why is a new stable release made for such an irrelevant bug? According to many, "nobody uses IPv6". Today's end-user never uses "traceroute". And a change in defconf will not affect people that just upgrade, only those that reset to defaults. That fact is not even mentioned in the article.
It would have been easier (and better) to publish a recommended change in the firewall rules.
Just want to understand.
It would have been easier (and better) to publish a recommended change in the firewall rules.
Just want to understand.
Re: v6.49.13 [stable] is released!
I diffed for you all:
6.49.10:
6.49.13:
6.49.10:
Code: Select all
filter add chain=input action=accept protocol=udp port=33434-33534 comment="defconf: accept UDP traceroute"Code: Select all
filter add chain=input action=accept protocol=udp dst-port=33434-33534 comment="defconf: accept UDP traceroute"Re: v6.49.13 [stable] is released!
+1It would have been easier (and better) to publish a recommended change in the firewall rules.
So as discussed many times before: a user that never touched the default firewall rules won't ever get this change automatically. It will stay broken until the user throws the device away or the user reviews his firewall filter rules and finds out: "hey, there was a change. need to adjust my rules.".
Why not just auto-migrate rules with the exact comment "defconf: accept UDP traceroute" (when not modified by user)? And even when the user has modified the firewall default rule: why not just show a red alert-line in winbox/cli that warns the user: "ding ding ding! alert! outdated firewall rule! here is a link to upgrade guide: insert URL to docs here"
Or is this rule already auto-migrated on upgrade to 6.49.13?
Or at very least minimum: write better changelogs. It is easy to maintain a separate page in MT docs (maybe called: "defconf changelog"). There you can reflect the exact change with a side by side diff (before/after). So anyone can see at a glance how default config changed over version/time.
Let's start writing proper documentation. Everyone can profit from it.
Re: v6.49.13 [stable] is released!
I diffed for you all:
Tanks 1000x! Now I can skip upgrade and do the right thing (which is harden the firewall) which wouldn't happen as @infabo rightfully points out).
And, BTW, 7.13.2 has same (erroneous) IPv6 firewall rule in default config.
And documentation as of writing this has the same rule ... https://help.mikrotik.com/docs/display/ ... ttheDevice
Re: v6.49.13 [stable] is released!
It is even worse! Most users of v6 (or those that migrated from v6) will have no IPv6 firewall AT ALL, because v6 comes with IPv6 disabled, and when you enable it (and reboot) it WILL NOT apply the default IPv6 configuration. So the firewall is empty.+1It would have been easier (and better) to publish a recommended change in the firewall rules.
So as discussed many times before: a user that never touched the default firewall rules won't ever get this change automatically. It will stay broken until the user throws the device away or the user reviews his firewall filter rules and finds out: "hey, there was a change. need to adjust my rules.".
Only when you reset to default config after enabling IPv6 (and also upgrading to the current version) you will get the default firewall config.
Reading the research by infabo it actually is a security issue. But as usual that was not mentioned in the release notes.
The default config, when it has been applied, opens e.g. the DNS resolver when source-port 33434-33534 is used, and it can be abused for DDoS amplification.
However, publishing an updated version will do nothing to rectify that.
Re: v6.49.13 [stable] is released!
As already mentioned by mkx, this rule is also part of ROS 7 default config. And IPv6 is there enabled by default.
Oh, "port" matches src- or dst-port. I see. Quite a bummer.
Oh, "port" matches src- or dst-port. I see. Quite a bummer.
Re: v6.49.13 [stable] is released!
Why is Mikrotik so cryptic in their changelogs?
For example: https://nvd.nist.gov/vuln/detail/CVE-2023-30799
This was some serious CVE score. But still the changelog of 6.49.7 (viewtopic.php?t=189970) looked like this:
This would make me cry - if I would be a professional IT infrastructure admin.
For example: https://nvd.nist.gov/vuln/detail/CVE-2023-30799
This was some serious CVE score. But still the changelog of 6.49.7 (viewtopic.php?t=189970) looked like this:
A CVE score 7+ and the only mentioning is:What's new in 6.49.7 (2022-Oct-11 17:37):
*) branding - fixed execution of "autorun.scr" file when installing branding package (introduced in v6.47);
*) routerboot - prevent enabling "protected-routerboot" on unsupported factory firmware versions;
*) routerboot - properly reset system configuration when protected bootloader is enabled and reset button used;
*) system - improved handling of user policies;
*) wireless - fixed disconnection of connected client while running background scan on wAP ac and wAP R ac devices;
*) wireless - fixed missing wireless interface on some RB921GS-5HPacD devices;
Code: Select all
*) system - improved handling of user policies;
Re: v6.49.13 [stable] is released!
This is very old. There is even a blog entry about it https://blog.mikrotik.com/security/cve-2023-30799.html
Re: v6.49.13 [stable] is released!
It was an example. Generally, MikroTik do not tell us in releasenotes what "improved handing" or "improved stability" mean w.r.t. security.
That is not right... and in the case of 6.49.13 it solves a security issue only for devices shipped with 6.49.13 installed. Are there any?
(no need to repeat what I think should be done with release notes - I explained that several times already)
That is not right... and in the case of 6.49.13 it solves a security issue only for devices shipped with 6.49.13 installed. Are there any?
(no need to repeat what I think should be done with release notes - I explained that several times already)
Re: v6.49.13 [stable] is released!
Indeed, it is very old.
But there is a gap in release of the fixed ROS version "6.49.7 (2022-Oct-11 17:37)" and the blog article from 27th Jul, 2023. I don't know why there is this time offset in fixing and announcing that something critical was fixed.
But there is a gap in release of the fixed ROS version "6.49.7 (2022-Oct-11 17:37)" and the blog article from 27th Jul, 2023. I don't know why there is this time offset in fixing and announcing that something critical was fixed.
Re: v6.49.13 [stable] is released!
This I want to know as well. It is much better with a new topic for every non RC/Beta release.Please explain:
Why are v7 release topics renamed and used throughout 7.13.x patch releases (7.13.1, 7.13.2, etc.) but on v6 there is still a separate topic for each release. 6.49.12 (and before all 6.49.x) got its own topic and now 6.49.13.
Just want to understand.
Also why 6.49.7 6.49.8 6.49.9 6.49.10 and 6.49.11 are long term releases, but
6.49.12 and 6.49.13 are just stable releases.
Re: v6.49.13 [stable] is released!
Usually such issues are fixed even before CVE is created. Thus, there is no CVE number to refer to. When there is an actual CVE available at the time of the release, then it is mentioned in the changelog. You can go through changelog history and see that by yourselves.
We do not "update" chagelogs after release, since they are usually right away re-published in many other sites and are out of our hands.
Also, CVE usually mentions versions affected.
We do not "update" chagelogs after release, since they are usually right away re-published in many other sites and are out of our hands.
Also, CVE usually mentions versions affected.
Re: v6.49.13 [stable] is released!
It was not critical. It requires full admin access. It's like you own your phone and you yourself would like to jailbreak it. In this case v7 was fixed immediately, because v7 is the current version. v6 is lower priority, since it is the EOL version.Indeed, it is very old.
But there is a gap in release of the fixed ROS version "6.49.7 (2022-Oct-11 17:37)" and the blog article from 27th Jul, 2023. I don't know why there is this time offset in fixing and announcing that something critical was fixed.
Re: v6.49.13 [stable] is released!
By the way guys, did you know anyone can publish a CVE, even if it's not? Just that it has a CVE number has zero meaning.
Re: v6.49.13 [stable] is released!
Now back to the topic. You published a new version to fix something in the default config. How do you think that publishing this new version is going to affect ANYTHING?
Should there, at minimum, not be some simple directions in the announcement article that explain what you need to change when you already have a configured router?
Should there, at minimum, not be some simple directions in the announcement article that explain what you need to change when you already have a configured router?
Re: v6.49.13 [stable] is released!
You are absolutely right about the secont part.
Firewall rule before the fix:
add action=accept chain=input comment="defconf: accept UDP traceroute" port=33434-33534 protocol=udp
Firewall rule now:
add action=accept chain=input comment="defconf: accept UDP traceroute" dst-port=33434-33534 protocol=udp
Firewall rule before the fix:
add action=accept chain=input comment="defconf: accept UDP traceroute" port=33434-33534 protocol=udp
Firewall rule now:
add action=accept chain=input comment="defconf: accept UDP traceroute" dst-port=33434-33534 protocol=udp
Re: v6.49.13 [stable] is released!
So devices with the old default firewall rule can potentially be used for DNS amplification attacks if the attacker uses these as source ports?
Re: v6.49.13 [stable] is released!
Yes. Mitigating factor is that first you have to know the address of the router. In IPv6 that is often not trivial.
Re: v6.49.13 [stable] is released!
Why not provide a migration script?You are absolutely right about the secont part.
Firewall rule before the fix:
add action=accept chain=input comment="defconf: accept UDP traceroute" port=33434-33534 protocol=udp
Firewall rule now:
add action=accept chain=input comment="defconf: accept UDP traceroute" dst-port=33434-33534 protocol=udp
Code: Select all
script removed - see better version below by mkx
Last edited by infabo on Wed Feb 07, 2024 7:05 pm, edited 1 time in total.
Re: v6.49.13 [stable] is released!
Why not provide a migration script?
Your script is inefficient ;-) . Here's one that does the same but using single command, fixed for use in v6:
Code: Select all
/ipv6 firewall filter set dst-port=33434-33534 !port [find comment="defconf: accept UDP traceroute" port=33434-33534]
Re: v6.49.13 [stable] is released!
I did not know that prefixing a value-name with "!" can unset it.
Re: v6.49.13 [stable] is released!
RouterOS itself should perform actions like that, as mentioned before (to change defaults when they are incorrect)....
Re: v6.49.13 [stable] is released!
It doesn't work in v7. The range of ports must be enclosed in quotes:Why not provide a migration script?
Your script is inefficient ;-) . Here's one that does the same but using single command, fixed for use in v6:
Code: Select all/ipv6 firewall filter set dst-port=33434-33534 !port [find comment="defconf: accept UDP traceroute" port=33434-33534]
Code: Select all
port="33434-33534"Re: v6.49.13 [stable] is released!
And your comment about ROS7 scripting is valid in a ROS6 thread because ... ???It doesn't work in v7. The range of ports must be enclosed in quotes:Code: Select allport="33434-33534"
Apples and oranges.
Re: v6.49.13 [stable] is released!
Well, maybe because when you have a router that originally had a v6 release before 6.49.13 with IPv6 enabled, and you upgraded it to v7, that wrong rule will still be there and has to be corrected.And your comment about ROS7 scripting is valid in a ROS6 thread because ... ???
Re: v6.49.13 [stable] is released!
Yes, that is exactly my case. I've upgraded the router from v6 to v7 before 6.49.13 came out.
Re: v6.49.13 [stable] is released!
New version v6.49.14 has been released:
viewtopic.php?t=206444
viewtopic.php?t=206444
Who is online
Users browsing this forum: eworm and 5 guests