4 ms·

(Copy of a comment I posted on ars): Microsoft hasn't contacted us (Samba) so this almost certainly isn't a protocol level bug (they're very good about being p

(Copy of a comment I posted on ars): Microsoft hasn't contacted us (Samba) so this almost certainly isn't a protocol level bug (they're very good about being proactive on these), but an error in their implementation of the SMB3 compression transform. In other words, a typical buffer overrun in a compression library. Gee, wonder where I've seen these before. Currently Samba doesn't implement the SMB3 transform header, an example where being slow to implement a feature is an advantage for once :-). So most Linux-based SMB3 servers and NAS boxes (which use Samba) will not be affected by this (I believe - things may change as more information becomes available).

kazinator 7y ago
Are you saying that Samba would use the same compression library as the Windows file sharing implementation, and so hit the same flaw?
- oneplane 7y ago
  If the bug was in a library supply by MS and used by SMB and Samba would use that library then the vulnerability would also be present in Samba. But that isn't the case, Samba re-implements the SMB client/server code in it's own library. A vulnerability that would transfer between different codebases would be protocol-level because all clients and servers that are to be compliant would have to implement the same protocol(s) and perhaps would easily all write identical state machines. Those kinds of errors are often range errors and logic errors as far as I know, which is a different kind of error as far was I have seen written about this compression bug.
- jra_samba 7y ago
  No, I'm saying that these kind of bugs in compression libraries are very common. We'll pick an open source one of course (we don't want to be in the writing and maintaining compression library business, just like we don't want to be in the crypto business), but we'd also be vulnerable to bugs in upstream if the compression library we use has them. I don't know what compression library Microsoft is using - probably they wrote their own.
gsam 7y ago
Have you seen any signs of which compression algorithm might be the one affected? Presumably it's one of their more snowflake ones. If it is in a library, surely SMB isn't the only affected resource? Perhaps it's not the library, but the plumbing or the headers and such.

kazinator 7y ago

Are you saying that Samba would use the same compression library as the Windows file sharing implementation, and so hit the same flaw?

oneplane 7y ago
If the bug was in a library supply by MS and used by SMB and Samba would use that library then the vulnerability would also be present in Samba. But that isn't the case, Samba re-implements the SMB client/server code in it's own library. A vulnerability that would transfer between different codebases would be protocol-level because all clients and servers that are to be compliant would have to implement the same protocol(s) and perhaps would easily all write identical state machines. Those kinds of errors are often range errors and logic errors as far as I know, which is a different kind of error as far was I have seen written about this compression bug.
jra_samba 7y ago
No, I'm saying that these kind of bugs in compression libraries are very common. We'll pick an open source one of course (we don't want to be in the writing and maintaining compression library business, just like we don't want to be in the crypto business), but we'd also be vulnerable to bugs in upstream if the compression library we use has them. I don't know what compression library Microsoft is using - probably they wrote their own.

gsam 7y ago

Have you seen any signs of which compression algorithm might be the one affected? Presumably it's one of their more snowflake ones. If it is in a library, surely SMB isn't the only affected resource? Perhaps it's not the library, but the plumbing or the headers and such.