RE: [SECURITY] Samba 2.2.8 available for download
Andrew Bartlett [mailto:[EMAIL PROTECTED] wrote: On Mon, 2003-03-31 at 06:12, Green, Paul wrote: Green, Paul [mailto:[EMAIL PROTECTED] wrote: The 2.2.8 release notes say: A buffer overrun condition exists in the SMB/CIFS packet fragment re-assembly code in smbd which would allow an attacker to cause smbd to overwrite arbitrary areas of memory in its own process address space. This could allow a skilled attacker to inject binary specific exploit code into smbd. I have written a short test case (available upon request) to confirm that Stratus VOS, when running on the HP PA-RISC hardware, is not susceptible to such an attack. While such an attack can indeed be used to insert code onto the VOS stack, as soon as the processor attempts to begin executing the code it will take a no-execute permission fault or an invalid-page fault. Therefore, the last sentence of this warning in the 2.2.8 release notes about inject[ing] binary specific exploit code into smbd does not apply to VOS on HP PA-RISC. As other experts have noted, there are probably other OS/Hardware combinations that are also immune to this attack. I hope other maintainers will post such information so that we can have a public record, and not needlessly scare our customers. I would not be so confident. You don't need to modify the code that will be executed, or cause a jump to your exploit to cause mischief. If you can overwrite an arbitrary position in memory, I'm sure you can find some variable that is critical to Samba's internal state, and go from there. I agree with your comment, but in my defense, I was trying to respond to the comment in the release notes about injecting binary-specific exploit code. That can't happen on VOS when it is running on PA-RISC. We're in the process of porting VOS to the Intel Pentium family, and one of the things we're investigating is how to prevent this same attack on that chip. We're reasonably confident we'll be able to prevent this attack there, too. I think most of the attempts to attack Samba on VOS would result in denial of service, but I agree it is possible that someone could get Samba to bypass one of its internal checks. I'm far more concerned about the issue of injecting binary-specific code, because a successful attack of that type would open up the entire resources of the machine to the attacker. Having said all this, because some of my customers are interested in receiving the 2.2.x version of Samba for VOS, and because the 2.2.x version has the fix for the buffer overruns, and also because 3.0 is not yet ready for prime time, I hope that the patches I'm submitting to 2.2.x will be applied. I'm willing to apply them myself, and monitor the build farm for any fallout, if I'm granted access. plug I've been porting Samba to VOS since version 2.0.5, working on POSIX and open-source software since 1996, and been a software developer since 1969. I have extensive experience in operating systems and compilers and have been the architect and lead developer for the Stratus VOS POSIX environment. I have made it a rule to test all patches on both VOS and Solaris before submitting them to samba-technical. I'm also the maintainer of the ports of Perl and OpenSSL to VOS, among others. /plug Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610
RE: [SECURITY] Samba 2.2.8 available for download
Green, Paul [mailto:[EMAIL PROTECTED] wrote: The 2.2.8 release notes say: A buffer overrun condition exists in the SMB/CIFS packet fragment re-assembly code in smbd which would allow an attacker to cause smbd to overwrite arbitrary areas of memory in its own process address space. This could allow a skilled attacker to inject binary specific exploit code into smbd. I have written a short test case (available upon request) to confirm that Stratus VOS, when running on the HP PA-RISC hardware, is not susceptible to such an attack. While such an attack can indeed be used to insert code onto the VOS stack, as soon as the processor attempts to begin executing the code it will take a no-execute permission fault or an invalid-page fault. Therefore, the last sentence of this warning in the 2.2.8 release notes about inject[ing] binary specific exploit code into smbd does not apply to VOS on HP PA-RISC. As other experts have noted, there are probably other OS/Hardware combinations that are also immune to this attack. I hope other maintainers will post such information so that we can have a public record, and not needlessly scare our customers. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus
RE: [SECURITY] Samba 2.2.8 available for download
On Mon, 2003-03-31 at 06:12, Green, Paul wrote: Green, Paul [mailto:[EMAIL PROTECTED] wrote: The 2.2.8 release notes say: A buffer overrun condition exists in the SMB/CIFS packet fragment re-assembly code in smbd which would allow an attacker to cause smbd to overwrite arbitrary areas of memory in its own process address space. This could allow a skilled attacker to inject binary specific exploit code into smbd. I have written a short test case (available upon request) to confirm that Stratus VOS, when running on the HP PA-RISC hardware, is not susceptible to such an attack. While such an attack can indeed be used to insert code onto the VOS stack, as soon as the processor attempts to begin executing the code it will take a no-execute permission fault or an invalid-page fault. Therefore, the last sentence of this warning in the 2.2.8 release notes about inject[ing] binary specific exploit code into smbd does not apply to VOS on HP PA-RISC. As other experts have noted, there are probably other OS/Hardware combinations that are also immune to this attack. I hope other maintainers will post such information so that we can have a public record, and not needlessly scare our customers. I would not be so confident. You don't need to modify the code that will be executed, or cause a jump to your exploit to cause mischief. If you can overwrite an arbitrary position in memory, I'm sure you can find some variable that is critical to Samba's internal state, and go from there. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: [SECURITY] Samba 2.2.8 available for download
Green, Paul wrote: However, on a chip that does distinguish areas of virtual memory that are code, and areas that are data, and further disallows execution of data (absent a specific operating system call to change the access mode of that region of virtual memory), it seems to me that it would be almost impossible for even a highly skilled attacker to inject binary specific code. I consider myself highly skilled on the Stratus VOS operating system and I can't for the life of my see how I could get the HP PA-RISC microprocessor to execute code that came down the wire as data. I'm inclined to think you're right: if I set stack and data spaces non-executable on my machine (a SPARC), it makes it distincltly harder to build an stack-overflow exploit. The writer can't insert a return address in the code he's added, but instead has to run something that already exists in the address space. In addition, if the code space is protected, it's hard for the attacker to put exploit code there. Intel and Samba experts, can you expand on this? --dave -- David Collier-Brown, | Always do right. This will gratify Sun Microsystems DCMO | some people and astonish the rest. Toronto, Ontario | (905) 415-2849 or x52849 | [EMAIL PROTECTED]
Re: [SECURITY] Samba 2.2.8 available for download
Paul Green wrote about potential vulnerabilities in getting a stack overflow to execute arbitrary code by an attacker. Many hardware platforms do have the protection that you describe, but it depends on the software to set up the protection. Also someone would need to have intimate knowlege of your platform to be able to write such an attack. The non-x86 platforms are probably less likely to be attacked in this manor from a virus. It may cause an application crash. And if you have someone internal that has the skill to do this, they probably are already privileged enough that they would have no problem compromising a system and covering their tracks. -John [EMAIL PROTECTED] Personal Opinion Only
RE: [SECURITY] Samba 2.2.8 available for download
The 2.2.8 release notes say: A buffer overrun condition exists in the SMB/CIFS packet fragment re-assembly code in smbd which would allow an attacker to cause smbd to overwrite arbitrary areas of memory in its own process address space. This could allow a skilled attacker to inject binary specific exploit code into smbd. Comment: It seems to me that the ability of a skilled attacker to inject binary specific exploit code into smbd is dependent upon the processor architecture. On a chip that fails to distinguish between code and data, I can readily see how a skilled attacker could inject binary specific code using a buffer overrun. However, on a chip that does distinguish areas of virtual memory that are code, and areas that are data, and further disallows execution of data (absent a specific operating system call to change the access mode of that region of virtual memory), it seems to me that it would be almost impossible for even a highly skilled attacker to inject binary specific code. I consider myself highly skilled on the Stratus VOS operating system and I can't for the life of my see how I could get the HP PA-RISC microprocessor to execute code that came down the wire as data. Question: Would someone please confirm or refute my hypothesis? Some of my customers are asking me about this vulnerability, and as all of the Stratus VOS customers are using Samba on a microprocessor that draws a strong distinction between virtual memory used for data (e.g., stack, heap, static data) versus virtual memory used by executable code, it is my current strong belief that we are not susceptible to this vulnerability as described in the release notes. [I can see how an attacker could mount a DoS attack, of course]. [[Meta comment: vulnerabilities that require combinations of code holes and microprocessor design flaws and/or operating system holes should be so labeled, IMHO. Blanket statements needlessly scare people, and needlessly let certain vendors of chips with weak hardware security controls, or OS vendors with same, off the hook.]] Patch Availability - - As this is a security issue, patches for this flaw specific to earlier versions of Samba will be posted on the [EMAIL PROTECTED] mailing list as requested. Well, if my hypothesis is incorrect, I'd like to request a patch against 2.0.7. Either that, or I'm going to send you a lot of patches to get 2.2.8 to build on VOS... Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Voice: +1 (978) 461-7557; FAX: +1 (978) 461-3610
Re: [SECURITY] Samba 2.2.8 available for download
Is 3.0 also vulnerable? Willi Mann From: Gerald (Jerry) Carter [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [SECURITY] Samba 2.2.8 available for download This release provides an important security fix outlined in the release notes that follow. This is the latest stable release of Samba and the version that all production Samba servers should be running for all current bug-fixes.
Re: [SECURITY] Samba 2.2.8 available for download
On Mon, Mar 17, 2003 at 08:13:15PM +0100, Willi Mann wrote: Is 3.0 also vulnerable? 3.0 is not released yet. 3.0 alphas are vulnerable, the SAMBA_3_0 code in CVS is not. Jeremy.
[SECURITY] Samba 2.2.8 available for download
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This release provides an important security fix outlined in the release notes that follow. This is the latest stable release of Samba and the version that all production Samba servers should be running for all current bug-fixes. The source code can be downloaded from : http://download.samba.org/samba/ftp/ in the file samba-2.2.8.tar.gz or samba-2.2.8.tar.bz2. The uncompressed tarball has been signed using the Samba Distribution Key (available in the same directory). Binary packages will be released shortly for major platforms and can be found at http://download.samba.org/samba/ftp/Binary_Packages/ As always, all bugs are our responsibility. --Sincerely The Samba Team * IMPORTANT: Security bugfix for Samba * Summary - --- The SuSE security audit team, in particular Sebastian Krahmer [EMAIL PROTECTED], has found a flaw in the Samba main smbd code which could allow an external attacker to remotely and anonymously gain Super User (root) privileges on a server running a Samba server. This flaw exists in previous versions of Samba from 2.0.x to 2.2.7a inclusive. This is a serious problem and all sites should either upgrade to Samba 2.2.8 immediately or prohibit access to TCP ports 139 and 445. Advice created by Andrew Tridgell, the leader of the Samba Team, on how to protect an unpatched Samba server is given at the end of this section. The SMB/CIFS protocol implemented by Samba is vulnerable to many attacks, even without specific security holes. The TCP ports 139 and the new port 445 (used by Win2k and the Samba 3.0 alpha code in particular) should never be exposed to untrusted networks. Description - --- A buffer overrun condition exists in the SMB/CIFS packet fragment re-assembly code in smbd which would allow an attacker to cause smbd to overwrite arbitrary areas of memory in its own process address space. This could allow a skilled attacker to inject binary specific exploit code into smbd. This version of Samba adds explicit overrun and overflow checks on fragment re-assembly of SMB/CIFS packets to ensure that only valid re-assembly is performed by smbd. In addition, the same checks have been added to the re-assembly functions in the client code, making it safe for use in other services. Credit - -- This security flaw was discovered and reported to the Samba Team by Sebastian Krahmer [EMAIL PROTECTED] of the SuSE Security Audit Team. The fix was prepared by Jeremy Allison and reviewed by engineers from the Samba Team, SuSE, HP, SGI, Apple, and the Linux vendor engineers on the Linux Vendor security mailing list. The Samba Team would like to thank SuSE and Sebastian Krahmer for their excellent auditing work and for drawing attention to this flaw. Patch Availability - - As this is a security issue, patches for this flaw specific to earlier versions of Samba will be posted on the [EMAIL PROTECTED] mailing list as requested. Protecting an unpatched Samba server Samba Team, March 2003 This is a note on how to provide your Samba server some protection against the recently discovered remote security hole if you are unable to upgrade to the fixed version immediately. Even if you do upgrade you might like to think about the suggestions in this note to provide you with additional levels of protection. Using host based protection --- In many installations of Samba the greatest threat comes for outside your immediate network. By default Samba will accept connections from any host, which means that if you run an insecure version of Samba on a host that is directly connected to the Internet you can be especially vulnerable. One of the simplest fixes in this case is to use the 'hosts allow' and 'hosts deny' options in the Samba smb.conf configuration file to only allow access to your server from a specific range of hosts. An example might be: hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24 hosts deny = 0.0.0.0/0 The above will only allow SMB connections from 'localhost' (your own computer) and from the two private networks 192.168.2 and 192.168.3. All other connections will be refused connections as soon as the client sends its first packet. The refusal will be marked as a 'not listening on called name' error. Using interface protection -- By default Samba will accept connections on any network interface that it finds on your system. That means if you have a ISDN line or a PPP connection to the Internet then Samba will accept connections on those links. This may not be what you want. You can change this behavior
