Any progress in patching this Vulnerability?
security@mikrotik.com be like
Very disappointing if this was disclosed to them in April! Luckily SMB is not a feature that should be enabled by most users.
Hope this wakes them Up!
Considering RPKI isn’t in Prod yet ;(
So sad! This’ a blow
Gentlemen, let me quote the Changelog:
What’s new in 6.46.7 (2020-Sep-07 07:38):
*) smb - fixed file path validation (introduced in v6.46);
*) smb - fixed possible memory leak;
*) smb - limit active session count to 5 per connection;
Normis, there is a section on the linked homepage of the CVE which states that the vulnerability was inded fixed in 6.47 but re-appeared in 6.47.2 and 6.47.3. Could you please have a look in this direction?
There is an entry for 6.47.2 which states
*) smb - fixed SMB server (introduced in v6.47);
So in 6.47 maybe SMB was broken anyway, so the vulnerability didn’t have what to crash?
Normis, I appreciate the new version which includes the fix, but please, do not fake release dates.
EDIT: Understood. Date is related to “build” not “release”.
This release was definitely not live week ago, on 7th September. Why does changelog (and your post) claim it was?
The topic with this release was published just one hour ago. And changelog page also did not list this change two days ago:
https://webcache.googleusercontent.com/search?q=cache:1DF1d6I9haIJ:https://mikrotik.com/download/changelogs+&cd=1&hl=en&ct=clnk&gl=au
If you are watching the release dates so close you’d notice that atleast the last 3 (maybe more) long term builds were released to public after ~7 days of probably inside testing since they were built.
Read first, blame later.
Cheers.
Changelog always has referenced last build date, not release date.
I do not check them “so closely” and I think in 99% of time few days does not matter. I accept your point that this may be part of the thorough testing process for Longterm branch. (I edited my original post now to reflect this)
But if BootlabsDev claims:
The bug was reported on 06.04.2020 and wasn’t fixed on 12.09.2020 even after multiple requests.
and normis responds:
Then it certainly does not feel right. It actually feels quite convenient for Mikrotik to have this long difference between “claimed release date” and “true release date” because now they can claim “he lies, we did fix it before 12 September”.
ps: And yes, I am again stirred up due to another CVE alegedly reported ages ago and not fixed until widely published.
There was a lot of discussion about this few years ago and general opinion of users was, that nobody minds if CVE is found because that happens. What people really don’t like is, if vendor actively refuses to fix reported vulnerability by denying it until whistleblower is forced to release it to public.
Communication could use improvements on the side of Mikrotik.
It is not lying but just not telling.
- the fixed version was ready last week but that was not communicated with the CVE publishers.
- in this thread Mikrotik should have written, “it was fixed last week and fix was released today”.
It is just the way of communicating that irritates the buyers. We are on your side and we are pleased that it was fixed but please don’t sit on it and don’t inform the ones finding it, and then insult your buyers by leaving out information claiming what you not had released yet.
Play by the rules and you have happy buyers of your products.
So what has be stumped here is what is vulnerable and what is not. The Github repro says this:
Affected Versions(tested)
6.41.3 (long term release)
6.45.8 (long term release)
6.45.9 (long term release)6.46.4 (stable release)
6.47.2 (stable)
6.47.3 (stable)7.0beta5 (beta)
7.1beta2 and below
So if true I would like to get a propper statement from Mikrotik on CVE-2020-11881 and why oooo why is this blog not updated with info (https://blog.mikrotik.com/security/)
You might as well close this as nothing is being added!
So with other words if the fixes from 6.47.2 and forward branch is in new Long-Term release we still have this issue as you can see that 6.47.2 is vulnerable again.
Currently only the long-term version channel (v6.46.7) has all the necessary fixes for this CVE. We are working on getting them published in stable and testing channels as well. Sorry for any inconvenience.
Thanks for the clarification.
Thanks.. Let’s wait for that.
Does anyone at Mikrotik have any update on when this CVE is going to be fixed. According to OpenVAS scans, even 7.3.x is still vulnerable and I haven’t found anything in the release notes to suggest its fixed.
Please provide some links with proper info when you wake up 2 years old topic.
Links for what? It’s a simple question on whether this CVE is fixed, as there’s no indication in the release notes it has been resolved in anything except 6.47.x.
This is from a recent scan of a customers group of MT’s.
All of their devices are running 7.3.1 as of 0300 this morning.