A look at the snort/src/dynamic-preprocessors/dcerpc/ directory of Snort CVS shows dcerpc.c and smb_andx_decode.c were modified three days ago to patch the vulnerability. You can check the diffs for dcerpc.c and smb_andx_decode.c to see how Sourcefire addressed the problem.
This level of transparency is one of my favorite aspects of open source projects. If you are so inclined you can check the source code to find the original vulnerability and then decide if the fix is proper.
There are probably a few dinosaurs out there who think this level of disclosure is too much, since it shows the adversary exactly where to find the problem. The truth is that several years of exceptionally effective reverse engineering of binary patches for closed, proprietary operating systems (and even creation of patches based on reverse engineering!) have demonstrated that hiding source code provides little to no secrecy. (Remember the source code for your favorite operating systems is probably already stolen anyway.)
The question is, what happens now? The slide below is from my TCP/IP Weapons School (layers 4-7) class. It's original research (meaning I didn't copy it from elsewhere, not that it's particularly awe-inspiring) based on analyzing Microsoft protocols. In the class we look at all of these protocols to see how they can be fragmented at the DCE/RPC and SMB layers. (For news on the next class in your area, visit my training schedule.) If you look at the slide you'll see DCE/RPC can appear in a variety of transports. This is worrisome given the vulnerability in Snort's DCE/RPC preprocessor. In 2005 in response to the Snort Back Orifice vulnerability I wondered if we might see a Snort worm. I don't think that will happen this time since it didn't happen last time.
On a related note, I finished writing the fourth Snort Report today. I cover upgrading to Snort 2.6.1.3 (which fixes the vulnerability) and how to check out Snort 2.7.0 from CVS to run a patched version of the 2.7.0 beta.
0 komentar:
Posting Komentar