[Samba] - Badlock Patches for AsusWRT-RMerlin?

[sfx2000]

Probably too soon for the factory firmware builds (QA driven), but anything on the RMerlin releases?

http://badlock.org

 

[RMerlin]

Actually, looks like this is old news. It's already patched in 380.59 beta (see the last CVE).

- FIXED: Backported security fixes from OpenWRT to Samba 3.6.25,
  addressing the following:
  CVE-2015-5252, CVE-2015-5370, CVE-2015-5296,
  CVE-2015-5299, CVE-2015-7560, CVE-2016-2110,
  CVE-2016-2111, CVE-2016-2112, CVE-2016-2115,
  CVE-2016-2118.

https://github.com/RMerl/asuswrt-merlin/commit/3e5247a2f9722e125a156bb5927491d33ed5a5b6

 

[L&LD]

Actually, looks like this is old news. It's already patched in 380.59 beta (see the last CVE).

- FIXED: Backported security fixes from OpenWRT to Samba 3.6.25,
  addressing the following:
  CVE-2015-5252, CVE-2015-5370, CVE-2015-5296,
  CVE-2015-5299, CVE-2015-7560, CVE-2016-2110,
  CVE-2016-2111, CVE-2016-2112, CVE-2016-2115,
  CVE-2016-2118.

RMerlin, was this the work of Asus or yourself?

(I'm assuming Asus).

 

[RMerlin]

RMerlin, was this the work of Asus or yourself?

(I'm assuming Asus).

Neither. It was the work of the OpenWRT devs (see the commit comment, I just added the link to my post).

 

[kvic]

Seems the vulnerabilities are exploitable on Samba >= 3.6. And only by a user from LAN which is much less an issue for home users.

Stock ASUSWRT aren't vulnerable (judging from the CVE's) because they use an older Samba (3.0.x ?)

Personally, I think not a top priority to fix but good to see it's already done for Merlin firmware.

 

[RMerlin]

Stock ASUSWRT aren't vulnerable (judging from the CVE's) because they use an older Samba (3.0.x ?)

Pretty sure they didn't bother checking if versions older than 3.6 were vulnerable, since they are supposed to have been EOL'ed years ago...

Unfortunately, until the Samba devs decide to do something about Samba being far too fat to fit in embedded devices, manufacturers will keep using such old versions. I read some discussion from this spring involving Samba developers, and their stance seems to pretty much be "if someone does something to reduce Samba's size, we'll merge it", meaning they won't do anything themselves. Just merging a standardized way of generating a multicall binary would already greatly help with Samba's flash footprint.

Another issue apparently is Samba's build system, which doesn't play nice (especially in newer 4.x versions) with cross compiling.

 

[kvic]

Pretty sure they didn't bother checking if versions older than 3.6 were vulnerable, since they are supposed to have been EOL'ed years ago...

Unfortunately, until the Samba devs decide to do something about Samba being far too fat to fit in embedded devices, manufacturers will keep using such old versions. I read some discussion from this spring involving Samba developers, and their stance seems to pretty much be "if someone does something to reduce Samba's size, we'll merge it", meaning they won't do anything themselves. Just merging a standardized way of generating a multicall binary would already greatly help with Samba's flash footprint.

Another issue apparently is Samba's build system, which doesn't play nice (especially in newer 4.x versions) with cross compiling.

Perhaps EOL is the reason it's not mentioned then.

I faintly recall reading Samba prefers forking processes to threads. Can't remember if true and for what reasons. BTW, Apple implements its own SMB daemon in recent versions of MacOS. Ditched Samba. Their own AFP is on the path to deprecation too.

Home router manufacturers are passively killing Samba feature maybe. Most of them have NAS ready to pick up customers..

 

[sfx2000]

I faintly recall reading Samba prefers forking processes to threads. Can't remember if true and for what reasons. BTW, Apple implements its own SMB daemon in recent versions of MacOS. Ditched Samba. Their own AFP is on the path to deprecation too.

Samba forks processes for portability purposes - easier than trying to support all the different threading models on the supported platforms...

Apple had to move away from Samba due to the Samba group changing the license over to GPLv3, which would have forced Apple to change their licensing - so reimplement was the only choice they had - and that has been an interesting path in a mixed platform environment...

 

[RMerlin]

BTW, Apple implements its own SMB daemon in recent versions of MacOS. Ditched Samba. Their own AFP is on the path to deprecation too.

Yeah, and interoperability for it blows. I frequently read of esoteric issues related to their implementation, which is also no doubt lagging behind in features (while the Samba team actually works with Microsoft).

Home router manufacturers are passively killing Samba feature maybe. Most of them have NAS ready to pick up customers..

Samba will remain necessary in embedded devices for years to come. Remember it's not just a server. Every media player out there needs Samba for their SMB client.