Bug 6768 - Specifically crafted stream of packets can force smbd into an infinite loop; CVE-2009-2906
Specifically crafted stream of packets can force smbd into an infinite loop; ...
Status: RESOLVED FIXED
Product: Samba 3.4
Classification: Unclassified
Component: File services
3.4.0
Other All
: P3 regression
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-29 13:03 UTC by Jeremy Allison
Modified: 2012-03-17 00:25 UTC (History)
2 users (show)

See Also:
metze: review+


Attachments
Torture test for this bug (not yet finished). (3.85 KB, patch)
2009-09-29 13:07 UTC, Jeremy Allison
no flags Details
Patch for master. (3.69 KB, patch)
2009-09-29 13:19 UTC, Jeremy Allison
vl: review+
Details
Patch for v3-4-test (3.60 KB, patch)
2009-09-29 13:19 UTC, Jeremy Allison
no flags Details
v3-3-test patch (3.54 KB, patch)
2009-09-29 14:54 UTC, Jeremy Allison
no flags Details
v3-2-test patch (3.54 KB, patch)
2009-09-29 14:55 UTC, Jeremy Allison
jra: review?
Details
Patch for 3.0.x. (2.95 KB, patch)
2009-09-29 17:53 UTC, Jeremy Allison
no flags Details
Proposal for an advisory (1.71 KB, text/plain)
2009-09-30 05:43 UTC, Volker Lendecke
no flags Details
More opaque advisory :-) (1.56 KB, text/plain)
2009-09-30 12:45 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2009-09-29 13:03:37 UTC
This is a denial of service security bug, found by Tim Prouty of Isilon.

17:01:28) tprouty: ok.  For an operation such as an unlink that does a createfile, it is possible that createfile will push the message onto the deferred open if it needs to wait for an oplock break.
(17:02:33) tprouty: When the unlink is eventually retried, if it hits any error case along the way that causes it to return before cleaning up the deferred open state inside of open_file_ntcreate, the deferred open won't be removed from the deferred open queue
(17:02:48) tprouty: And thus the operation will be tried continuously.
(17:04:34) tprouty: The specific case we caught internally (and the one that I wrote a torture test for) is when another client unlinks the file after the first client tried the unlink, but before the first client received the break notification and completed it's unlink.
(17:05:20) tprouty: There could presumably be other paths susceptible to this, including rename.

This bug has been assigned the CVE number : CVE-2009-2906.

Jeremy.
Comment 1 Jeremy Allison 2009-09-29 13:07:29 UTC
Created attachment 4756 [details]
Torture test for this bug (not yet finished).
Comment 2 Jeremy Allison 2009-09-29 13:19:17 UTC
Created attachment 4757 [details]
Patch for master.
Comment 3 Jeremy Allison 2009-09-29 13:19:49 UTC
Created attachment 4758 [details]
Patch for v3-4-test
Comment 4 Jeremy Allison 2009-09-29 14:54:45 UTC
Created attachment 4760 [details]
v3-3-test patch

Still needs testing - but should be ok.
Comment 5 Jeremy Allison 2009-09-29 14:55:17 UTC
Created attachment 4761 [details]
v3-2-test patch

Still needs testing - but should be ok.
Comment 6 Jeremy Allison 2009-09-29 17:53:05 UTC
Created attachment 4762 [details]
Patch for 3.0.x.

Testing all versions follows....
Comment 7 Jeremy Allison 2009-09-29 19:03:24 UTC
Confirmed 3.0.x patch works with torture test.
Jeremy.
Comment 8 Jeremy Allison 2009-09-29 19:18:07 UTC
Confirmed 3.2 patch works with torture test.
Jeremy.
Comment 9 Jeremy Allison 2009-09-29 19:41:47 UTC
Confirmed 3.3 works with torture test. As Tim already confirmed 3.4 this patch is ready for all versions once Volker or Metze has reviewed.

Jeremy.
Comment 10 Volker Lendecke 2009-09-30 05:43:22 UTC
Created attachment 4763 [details]
Proposal for an advisory
Comment 11 Jeremy Allison 2009-09-30 10:41:34 UTC
Do we really want to explicitly list the *exact* packet stream that will cause us to spin ? :-).

I'd prefer to say something like :

"An unexpected reply to an oplock break can cause....".

Let those who want to create exploits have to read the code :-).

Jeremy.
Comment 12 Volker Lendecke 2009-09-30 12:35:03 UTC
Sure, fine by me.

Volker
Comment 13 Jeremy Allison 2009-09-30 12:45:09 UTC
Created attachment 4767 [details]
More opaque advisory :-)
Comment 14 Volker Lendecke 2009-09-30 12:47:51 UTC
Looks good, thanks.

Volker
Comment 15 Stefan Metzmacher 2009-10-01 02:29:55 UTC
From reading the patches, they look good.

Also the opaque advisory is fine.

metze
Comment 16 Karolin Seeger 2009-10-01 07:43:12 UTC
Fix has been pushed to all branches and is included in 3.0.37, 3.2.15, 3.3.8 and 3.4.2. Closing out bug report.