Now that the badlock bug and fixes are available, it is too much for some companies
abartlet at samba.org
Thu Apr 14 07:27:14 UTC 2016
On Thu, 2016-04-14 at 10:18 +0300, Uri Simchoni wrote:
> On 04/14/2016 09:58 AM, Andrew Bartlett wrote:
> > On Wed, 2016-04-13 at 11:52 -0700, Richard Sharpe wrote:
> > >
> > > I am suggesting it as an interim solution that mitigates the risk
> > > while we get the complete solution through the organization
> > > because
> > > QA
> > > is going to require a long testing cycle because of the amount of
> > > code
> > > change that it involves.
> > >
> > Do you enforce SMB signing in your product? If not, MITM attacks
> > against SMB (and so ncacn_np) are much easier to do than exploiting
> > this issue. The reason the release came with so many other fixes
> > is
> > that only with them all fixed and signing required on all protocols
> > doe
> > s it make sense.
> > The rest is a pile of correctness stuff that is worthwhile, but put
> > another way, if the front door is unlocked, checking the deadbolt
> > on
> > the patio isn't much help.
> > Andrew Bartlett
> ... But even without SMB signing, the SAMR pipe usually has (and
> the patch - always has?) its own integrity/confidentiality provided
> RPC, isn't it?
Not for ncacn_np. That uses the SMB session only.
> I mean, if I try to change the password of a local user
> on an SMB server, everything is encrypted (and the way I understood
> badlock, an MITM could prevent this encryption, and without SMB
> as an additional security measure, hijack the connection and
> local users at will)
It all depends what options were selected, but if an attacker can take
over your SMB connection, they can open a new ncacn_np pipe and do what
Administratively setting passwords isn't possible without knowing the
session key, but so much else can be done that isn't really much help.
Password changes are a bit different, they use their own 'encrypt new
password with old password' scheme, designed to be secure over
anonymous RPC, so don't impact on this either way.
The attacks on SMB and ncacn_np has been well known for decades. The
embarrassing part was that when we implemented Samba4, we did enforce
SMB signing, but but when we did s3fs, we didn't write a strict test to
ensure we kept doing that (and no, we didn't).
I hope this helps,
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical