Re: My machine was hacked - possibly via sshd?
On Mon, 28 Mar 2005, Noah Meyerhans wrote: > It should be noted that it is entirely possible, even on today's > internet, to run a large network completely exposed to the internet. It > always makes me sad when I hear people talking as though you simply > *must* have a firewall, or else you're endangering yourself, your users, I would say this is true up to a point but it does have some caveats: - It presumes an admin is diligently keeping up to date with patches. In a perfect world this would always be true. - It presumes the vendor(s) are providing patches in a timely manner. - It presumes that no misconfigurations exist. Plenty of misconfigurations occur when they should not and the firewall may be the only thing that stops in intrusion in this case. - It tends to violate the principal of "Security in depth". Stay fully patched and have a firewall (and IDS) as well. - It ignores the advantages of rate limiting capabilities built into many firewalls (such as iptables). - It ignores the fact that being able to probe a network may be useful for a future attack. I do agree that admins should always consider why they are doing something, like putting in a firewall, rather than just blindly doing it. > and the internet community as a whole. You can run with "default allow" > policy, and do it safely. Firewalls cause two major problems. First of > all, they lead to a false sense of security. They create a "soft IMHO user/admin education is the key here. > underbelly" with a hard shell. If you can get through the shell, who I do agree. Internal firewalls may be needed, or other measures. I won't go into this topic, as it is quite open ended. > due to strict firewall policies. These users, or the developers of The work of a modern admin is very much a balance between functionality and security. > their software, invariably will find some way to get their traffic > through. Witness all the stuff that gets tunneled over HTTP or ssh Yep, that annoys me, and I do recognise the core problem. Very often they are just trying to do their job when they tunnel data like that too. Wonderful isn't it. IMHO it comes down to intelligently assessing the needs of the organisation. Too few admins are doing that today (IMHO). Cheers, Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: [EMAIL PROTECTED] http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (http://www.spi-inc.org) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My machine was hacked - possibly via sshd?
On Mon, 28 Mar 2005, Malcolm Ferguson wrote: > My machine was cracked on Thursday evening. I'm trying to understand how it > happened so that it doesn't go down again. I note below you rebuilt the box. This is great. If you are sure you knew this is the date of the crack you could have restored from a previous backup and used that as a base for restoring to the present state. Only do this if you are _sure_ you know when the crack occured. The date it becomes evident need not be the date it happened. Smart crackers will stay undetected for as long as they can. > Machine was running Debian 3.0 and was behind a NAT box with ports forwarded > for SMTP, HTTP and SSH. It hadn't been rebooted for 430 days. I was using a So the box had several local root exploits in the kernel and possibly various library and other exploits hanging around (even though it was patched - see below). > Early on the 25th, my logcheck emails indicated increasing messages in syslog > concerning failed login attempts against ssh. At some point though I see ssh > authentication failures for valid user names - how? Somehow they were being > enumerated in the hack attempt, and I think that one person had a weak Although it can be difficult to manage with a large number of users I strongly encourage moving towards blocking password access to ssh entirely. One way to approach this is to announce it now and give users 90 days to arrange for public keys to be present in their accounts. You could also post some docs on how to go about generating a key pair. > password. Finally I see an attempt to load net-pf-14 and other modprobe > errors. At some point there are also messages about the ethernet card > entering promiscuous mode. It was probably already over by this point. They were probably out trying to learn more. > When I logged on I discovered two outgoing connections to port ircd on the > foreign hosts, and some thing listening on port 48744 TCP. No PID associated A kernel module to hide the processes may have been loaded. > So what can I do to prevent it? My best guess is that ssh failed, but Keep the system patched and bare in mind that once a system is patched you need to flush out all old copies of binaries and libraries. This is more of a problem with library updates. Update the kernel to avoid the various local root exploits seen over the last couple of years. Yes this means a reboot ;) > this is based on the log messages. Exim or Apache could have been the > point of failure too though. Seeing as it was so long since I rebooted, > perhaps the exploit was coupled with a kernel vulnerability. Any Exactly - a local root exploit combined with a remote non-root exploit can hand the keys to the kingdom to an attacker. > I no longer have a single partition, but about 10, including read-only ones > for /usr and /boot. I'm also running the Debian stock 2.4.18-1-586tsc Not as useful as you might think... mount -n -o remount,rw /usr Have you considered running SELinux? This is a non-trivial exercise of course. Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: [EMAIL PROTECTED] http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (http://www.spi-inc.org) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [meta] Set reply-to to something else?
On Wed, 19 Jan 2005, Vassilii Khachaturov wrote: > I hope that I am not the only one who writes to the auto-ackers and > their postmasters that they're using stupid MUAs not honoring > Precedence: bulk > or > Precedence: junk > as well as the other list-control fields as a flags to not auto-respond. I reply and point out that Unix vacation(1) has been working correctly with lists for 20 or 30 years and ask why software written in the last 5 years for a certain other OS can't follow a few simple rules :) Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Patches that break stuff
Hi all. I think this is on-topic for the security list since all Stable package updates I see are security related. On Bugtraq the issue of patches breaking various parts of an OS has been raised (under the thread "Microsoft and Security"). It has been noted by one participant that his company assessed how often patches had to be replaced because their were broken in some way. They came to the figure of 1 in 6 patches needed replacing. In a private email the poster reported: 1. All vendors were within 3% of this figure. He advises they did lump all Linux distros together. 2. Cisco was lowest and Microsoft was average. I've found Debian puts all other "vendors" to shame when it comes to stability of updates to the Stable branch. Are any hard stats available on how many Debian package upgrades have had to be replaced because they broke something? I'm thinking the total number of broken updates in 2.2 and 3.0 is 0 plus or minus 1 :) Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
On Thu, 9 Oct 2003, Ted Cabeen wrote: > I agree. If you are looking for this kind of security, your best bet > is to set the immutable bit on all of your system files. That will > ensure that only a reboot in single user mode will allow these files > to be changed. (Make sure you set immutable the system boot scripts > as well) The immutable bit can be removed from a file on a running system. I just confirmed this on a box to make sure recent kernels hadn't changed this behaviour. Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah
Re: How efficient is mounting /usr ro?
On Thu, 9 Oct 2003, Bernhard R. Link wrote: > security one gets by this is that this way /usr has no chance to > go corrupt when de power supply fails and less possible corruption Well, no chance from software related issues (files not writing properly, etc) but an electrical surge could still do in the filesystem. > make it less propable that a corruption helping an attacker accours. True. > On the other hand if you then forget to remount it rw when updating > packages this may corrupt your system helping an attacker in. IIRC I did something like this a few years ago and it didn't cause corruption, it just resulted in the package installation failing. > On the other hand one should not over-estimate the inteligence of > script-kiddies. Even those writing the scripts tend to be lousy > programers, from what I have seen. Indeed. Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah
Re: How efficient is mounting /usr ro?
On Thu, 9 Oct 2003, Ted Cabeen wrote: > I agree. If you are looking for this kind of security, your best bet > is to set the immutable bit on all of your system files. That will > ensure that only a reboot in single user mode will allow these files > to be changed. (Make sure you set immutable the system boot scripts > as well) The immutable bit can be removed from a file on a running system. I just confirmed this on a box to make sure recent kernels hadn't changed this behaviour. Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
On Thu, 9 Oct 2003, Bernhard R. Link wrote: > security one gets by this is that this way /usr has no chance to > go corrupt when de power supply fails and less possible corruption Well, no chance from software related issues (files not writing properly, etc) but an electrical surge could still do in the filesystem. > make it less propable that a corruption helping an attacker accours. True. > On the other hand if you then forget to remount it rw when updating > packages this may corrupt your system helping an attacker in. IIRC I did something like this a few years ago and it didn't cause corruption, it just resulted in the package installation failing. > On the other hand one should not over-estimate the inteligence of > script-kiddies. Even those writing the scripts tend to be lousy > programers, from what I have seen. Indeed. Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Watch out! vsftpd anonymous access always enabled!
On Sat, 20 Sep 2003, Robert van der Meulen wrote: > If anyone here is running vsftpd on a non-anonymous box, I'd make sure to > check this too. In the case of this customer (who has pretty sensitive data > on his box), this could have been quite a disaster. If he really cares about the data (and let's face it, everyone cares about their data :) then I'd recommend dispensing with ftp entirely and using scp or sftp (ssh v2) if the client needs to shift data to or from the box. Configure this for RSA/DSA access only (no password access) and possibly lock it down with a firewall as well (after recent events). You can even go one step further and have the sensitive data seperated from the upload/download box (there are various ways to aproach this). Cheers, Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah
Re: Watch out! vsftpd anonymous access always enabled!
On Sat, 20 Sep 2003, Robert van der Meulen wrote: > If anyone here is running vsftpd on a non-anonymous box, I'd make sure to > check this too. In the case of this customer (who has pretty sensitive data > on his box), this could have been quite a disaster. If he really cares about the data (and let's face it, everyone cares about their data :) then I'd recommend dispensing with ftp entirely and using scp or sftp (ssh v2) if the client needs to shift data to or from the box. Configure this for RSA/DSA access only (no password access) and possibly lock it down with a firewall as well (after recent events). You can even go one step further and have the sensitive data seperated from the upload/download box (there are various ways to aproach this). Cheers, Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sendmail package version weirdness
On Fri, 19 Sep 2003, Matt Zimmerman wrote: > On Thu, Sep 18, 2003 at 10:58:49PM -0400, Robert Brockway wrote: > > > Was there any particular reason that this newer fixed version has a > > version number the makes it look older than the exploitable version? > > Simple: it doesn't. The version in stable is 8.12.3-4, and the version on > security.debian.org is 8.12.3-6.6. Your package came from someplace else. Hi Matt. Thanks for clearing that up. FYI I located the origin of the version I was using: http://people.debian.org/~cowboy/sendmail_8.12.3-7woody_i386.changes Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah
Re: Sendmail package version weirdness
On Fri, 19 Sep 2003, Matt Zimmerman wrote: > On Thu, Sep 18, 2003 at 10:58:49PM -0400, Robert Brockway wrote: > > > Was there any particular reason that this newer fixed version has a > > version number the makes it look older than the exploitable version? > > Simple: it doesn't. The version in stable is 8.12.3-4, and the version on > security.debian.org is 8.12.3-6.6. Your package came from someplace else. Hi Matt. Thanks for clearing that up. FYI I located the origin of the version I was using: http://people.debian.org/~cowboy/sendmail_8.12.3-7woody_i386.changes Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sendmail package version weirdness
Hi all. I took preventative measures to protect my exploitable sendmail
until I could get the new package installed on my mail server (running
Debian Stable). I did the usual sudo apt-get update && sudo apt-get
upgrade but wasn't seeing the new package.
A little bit of investigation showed the problem. The version I was
running (exploitable) was 8.12.3-7woody so when I tried to upgrade to the
newer fixed version (8.12.3-6.6) it ways always seeing this as an older
version & failing to install it.
Was there any particular reason that this newer fixed version has a
version number the makes it look older than the exploitable version?
Surely this will make life harder for people wanting to upgrade since the
normal apt0-get method will fail. Was it just a mjessup with version
numbering? :) If it was I'd suggest the fixed sendmail be re-issued with
a higher version number to fix the problem.
Thanks again, must have been a busy few days for you :)
Cheers,
Rob
--
Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Linux counter project ID #16440 (http://counter.li.org)
"The earth is but one country and mankind its citizens" -Baha'u'llah
Sendmail package version weirdness
Hi all. I took preventative measures to protect my exploitable sendmail
until I could get the new package installed on my mail server (running
Debian Stable). I did the usual sudo apt-get update && sudo apt-get
upgrade but wasn't seeing the new package.
A little bit of investigation showed the problem. The version I was
running (exploitable) was 8.12.3-7woody so when I tried to upgrade to the
newer fixed version (8.12.3-6.6) it ways always seeing this as an older
version & failing to install it.
Was there any particular reason that this newer fixed version has a
version number the makes it look older than the exploitable version?
Surely this will make life harder for people wanting to upgrade since the
normal apt0-get method will fail. Was it just a mjessup with version
numbering? :) If it was I'd suggest the fixed sendmail be re-issued with
a higher version number to fix the problem.
Thanks again, must have been a busy few days for you :)
Cheers,
Rob
--
Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Linux counter project ID #16440 (http://counter.li.org)
"The earth is but one country and mankind its citizens" -Baha'u'llah
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Pat on the back
Hi. I just wanted to say thanks to the security team for the rapid deployment of the fixed versions of OpenSSH (twice). Often people are quick to post negative emails and not so quick to post positive emails, so I just wanted to say that many of us really do appreciate the work the security team does. Knowing that fixed versions will be in the security archive quickly helps to keep my blood pressure down :) Cheers, Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah
Pat on the back
Hi. I just wanted to say thanks to the security team for the rapid deployment of the fixed versions of OpenSSH (twice). Often people are quick to post negative emails and not so quick to post positive emails, so I just wanted to say that many of us really do appreciate the work the security team does. Knowing that fixed versions will be in the security archive quickly helps to keep my blood pressure down :) Cheers, Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED] Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulnerability in the wild
On Tue, 16 Sep 2003, Josh Carroll wrote:
> Actually, people have reported that there is an exploit, and in fact
> even OpenBSD is vulnerable.
A number of people have claimed that others have said it is exploitable.
This is quite a common occurance with well publicised exploits.
I've seen no proof of an exploit as yet.
> I would still patch ASAP. Best not to risk it.
Definately. This is always best practice regardless of whether there is a
known exploit or not.
Cheers,
Rob
--
Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Linux counter project ID #16440 (http://counter.li.org)
"The earth is but one country and mankind its citizens" -Baha'u'llah
Re: ssh vulnerability in the wild
On Tue, 16 Sep 2003, Josh Carroll wrote:
> Actually, people have reported that there is an exploit, and in fact
> even OpenBSD is vulnerable.
A number of people have claimed that others have said it is exploitable.
This is quite a common occurance with well publicised exploits.
I've seen no proof of an exploit as yet.
> I would still patch ASAP. Best not to risk it.
Definately. This is always best practice regardless of whether there is a
known exploit or not.
Cheers,
Rob
--
Robert Brockway B.Sc. email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Linux counter project ID #16440 (http://counter.li.org)
"The earth is but one country and mankind its citizens" -Baha'u'llah
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
sendmail 8.12.9 available
Hi hadn't seen this mentioned on list. Forwarded from Bugtraq. -- Forwarded message -- Sendmail, Inc., and the Sendmail Consortium announce the availability of sendmail 8.12.9. It contains a fix for a critical security problem discovered by Michal Zalewski whom we thank for bringing this problem to our attention. Sendmail urges all users to either upgrade to sendmail 8.12.9 or apply a patch for your sendmail version that is part of this announcement. Remember to check the PGP signatures of patches or releases obtained via FTP or HTTP (to check the correctness of the patches in this announcement please verify the PGP signature of it). For those not running the open source version, check with your vendor for a patch. We apologize for releasing this information today (2003-03-29) but we were forced to do so by an e-mail on a public mailing list (that has been sent by an irresponsible individual) which contains information about the security flaw. For a complete list of changes see the release notes down below. Please send bug reports to [EMAIL PROTECTED] as usual. Note: We have changed the way we digitally sign the source code distributions to simplify verification: in contrast to earlier versions two .sig files are provided, one each for the gzip'ed version and the compressed version. That is, instead of signing the tar file, we sign the compressed/gzip'ed files, so you do not need to uncompress the file before checking the signature. This version can be found at ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.gz ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.gz.sig ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.Z ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.Z.sig and the usual mirror sites. MD5 signatures: 3dba3b6d769b3681640d0a38b0eba48c sendmail.8.12.9.tar.gz 19e39c9e9bc8fae288245c546639e1f4 sendmail.8.12.9.tar.gz.sig 268fc4045ba3eac6dfd9dc95d889ba5f sendmail.8.12.9.tar.Z 19e39c9e9bc8fae288245c546639e1f4 sendmail.8.12.9.tar.Z.sig You either need the first two files or the third and fourth, i.e., the gzip'ed version or the compressed version and the corresponding .sig file. The PGP signature was created using the Sendmail Signing Key/2003, available on the web site (http://www.sendmail.org/) or on the public key servers. Since sendmail 8.11 and later includes hooks to cryptography, the following information from OpenSSL applies to sendmail as well. PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS PACKAGE TO YOUR COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER PEOPLE YOU ARE STRONGLY ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHORS ARE NOT LIABLE FOR ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT IS YOUR RESPONSIBILITY. SENDMAIL RELEASE NOTES $Id: RELEASE_NOTES,v 8.1340.2.132 2003/03/29 14:02:26 ca Exp $ This listing shows the version of the sendmail binary, the version of the sendmail configuration files, the date of release, and a summary of the changes in that release. 8.12.9/8.12.9 2003/03/29 SECURITY: Fix a buffer overflow in address parsing due to a char to int conversion problem which is potentially remotely exploitable. Problem found by Michal Zalewski. Note: an MTA that is not patched might be vulnerable to data that it receives from untrusted sources, which includes DNS. To provide partial protection to internal, unpatched sendmail MTAs, 8.12.9 changes by default (char)0xff to (char)0x7f in headers etc. To turn off this conversion compile with -DALLOW_255 or use the command line option -d82.101. To provide partial protection for internal, unpatched MTAs that may be performing 7->8 or 8->7 bit MIME conversions, the default for MaxMimeHeaderLength has been changed to 2048/1024. Note: this does have a performance impact, and it only protects against frontal attacks from the outside. To disable the checks and return to pre-8.12.9 defaults, set MaxMimeHeaderLength to 0/0. Do not complain about -ba when submitting mail. Problem noted by Derek Wueppelmann. Fix compilation with Berkeley DB 1.85 on systems that do not have flock(2). Problem noted by Andy Harper of Kings College London. Properly initialize data structure for dns maps to avoid various errors, e.g., looping processes. Problem noted by Mauri
Sendmail exploit
Hi, hadn't seen this mentioned on list. Forwarded from Bugtraq. Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED] ICQ: 104781119 Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- Forwarded message -- CVE: CAN-2003-0161 CERT: VU#897604 *** FORCED RELEASE -- VENDOR NOTIFIED AS OF 03/18/03 *** There is a vulnerability in Sendmail versions 8.12.8 and prior. The address parser performs insufficient bounds checking in certain conditions due to a char to int conversion, making it possible for an attacker to take control of the application. This problem is not related to the recent ISS vulnerability announcement. The impact is believed to be a root compromise. I've confirmed this is a local issue, and my initial impression is that a remote attack possibility is not that unlikely. Only platforms with 'char' type signed by default are vulnerable as-is, and little endian systems would be easier to exploit. Systems that use Sendmail privilege separation are safer against the _local_ attack, but even then it is still possible to compromise the smmsp account and control the submission queue. The bug lurks in parseaddr.c in prescan() function, which, in certain conditions, will run past the buffer size limit and overwrite stack variables, reaching to and past the stored instruction pointer itself. This function is called quite generously accross the code for processing e-mail addresses. It is possible for the attacker to repeatedly skip the length check location in this function because of an unfortunate construction of a "special" control value check. A special value, NOCHAR, is defined as -1. There is a variable 'c', also used to store last read character, declared as int, and the variable will be sometimes assigned the value of NOCHAR to indicate a special condition. Unfortunately, the input character - type char - defaults to a signed type on many modern platforms, and ASCII value 0xff ((char)-1) will be converted to 0x ((int)-1) upon assignment. This makes character 0xff indistinguishable from NOCHAR after being stored in 'c', and makes it possible for the attacker to spoof NOCHAR and skip the length check. Since precise control of the overwrite process is possible (length, offset and layout are up to the attacker), even though the values are mostly fixed, it is reasonable to expect that this vulnerability will be easy to exploit on little endian systems. Even on big endian systems, it might be still possible to alter important control variables on the stack, and you are generally advised to upgrade. I've notified the vendor on March 18, and got a response on the next day. Sendmail is releasing version 8.12.9, and the official notice is as follows: Sendmail, Inc., and the Sendmail Consortium announce the availability of sendmail 8.12.9. It contains a fix for a critical security problem discovered by Michal Zalewski whom we thank for bringing this problem to our attention. Sendmail urges all users to either upgrade to sendmail 8.12.9 or apply a patch for your sendmail version. Remember to check the PGP signatures of patches or releases obtained via FTP or HTTP (to check the correctness of the patches in this announcement please verify the PGP signature of it). For those not running the open source version, check with your vendor for a patch. SECURITY: Fix a buffer overflow in address parsing due to a char to int conversion problem which is potentially remotely exploitable. Problem found by Michal Zalewski. Please visit http://www.sendmail.org for more details and patches, and check with your vendor for the availability of a new or patched package.
Re: iptables forwarding to inside firewall
On Fri, 28 Mar 2003, Hanasaki JiJi wrote: > Working on running a SMTP server inside the firewall that takes incoming > SMTP traffic from outside the firewall. The below rules are not > working. The firewall refuses connections. Any input on what wrong? There has been quite a bit of discussion on the mechanics of setting up the port redirection to a box inside your firewall. I'd like to mention the potential folly of doing this. By doing a port redirect from from port 25 on your firewall to port 25 on a box inside you are effectively exposing the internal host to the Internet on this port, circumventing your firewall. If a remote exploit is found in the MTA running on your internal host (as has just occured with sendmail again), an attacker may be able to launch a direct attack on this box. Depending on your overall security structure they may then be able to attack any number of hosts behind your firewall. Some of the alteratives aren't much better. Running an MTA on your firewall is just as bad as a remote exploit here may allow an attack access to the root on the firewall, allowing the firewall to be circumvented again. If you have more than 1 static address, an MTA running in a DMZ is definately better. This way you could still have your internal MTA being port forwarded by restrict access through the firewall by source address, such that only your MTA in the DMZ can access the port redirect. If you can restrict access by way of network interface on the firewall[1] then you're much much better off again as this protects against a spoof. [1] If you use the "3 legged firewall" setup, it is possible to distinguish DMZ traffic from other traffic based on which interface it is entering the firewall. This all presupposes you have been allocated a subnet of static addresses by your ISP. If this is for a home setup you may not be able to do much about the security aspect or it may not be worth it to setup a DMZ (this is perfectly valid, it's all about risk assessment), but it's always worth considering the alternatives. Cheers, Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED] ICQ: 104781119 Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah
sendmail 8.12.9 available
Hi hadn't seen this mentioned on list. Forwarded from Bugtraq. -- Forwarded message -- Sendmail, Inc., and the Sendmail Consortium announce the availability of sendmail 8.12.9. It contains a fix for a critical security problem discovered by Michal Zalewski whom we thank for bringing this problem to our attention. Sendmail urges all users to either upgrade to sendmail 8.12.9 or apply a patch for your sendmail version that is part of this announcement. Remember to check the PGP signatures of patches or releases obtained via FTP or HTTP (to check the correctness of the patches in this announcement please verify the PGP signature of it). For those not running the open source version, check with your vendor for a patch. We apologize for releasing this information today (2003-03-29) but we were forced to do so by an e-mail on a public mailing list (that has been sent by an irresponsible individual) which contains information about the security flaw. For a complete list of changes see the release notes down below. Please send bug reports to [EMAIL PROTECTED] as usual. Note: We have changed the way we digitally sign the source code distributions to simplify verification: in contrast to earlier versions two .sig files are provided, one each for the gzip'ed version and the compressed version. That is, instead of signing the tar file, we sign the compressed/gzip'ed files, so you do not need to uncompress the file before checking the signature. This version can be found at ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.gz ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.gz.sig ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.Z ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.Z.sig and the usual mirror sites. MD5 signatures: 3dba3b6d769b3681640d0a38b0eba48c sendmail.8.12.9.tar.gz 19e39c9e9bc8fae288245c546639e1f4 sendmail.8.12.9.tar.gz.sig 268fc4045ba3eac6dfd9dc95d889ba5f sendmail.8.12.9.tar.Z 19e39c9e9bc8fae288245c546639e1f4 sendmail.8.12.9.tar.Z.sig You either need the first two files or the third and fourth, i.e., the gzip'ed version or the compressed version and the corresponding .sig file. The PGP signature was created using the Sendmail Signing Key/2003, available on the web site (http://www.sendmail.org/) or on the public key servers. Since sendmail 8.11 and later includes hooks to cryptography, the following information from OpenSSL applies to sendmail as well. PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS PACKAGE TO YOUR COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER PEOPLE YOU ARE STRONGLY ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHORS ARE NOT LIABLE FOR ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT IS YOUR RESPONSIBILITY. SENDMAIL RELEASE NOTES $Id: RELEASE_NOTES,v 8.1340.2.132 2003/03/29 14:02:26 ca Exp $ This listing shows the version of the sendmail binary, the version of the sendmail configuration files, the date of release, and a summary of the changes in that release. 8.12.9/8.12.9 2003/03/29 SECURITY: Fix a buffer overflow in address parsing due to a char to int conversion problem which is potentially remotely exploitable. Problem found by Michal Zalewski. Note: an MTA that is not patched might be vulnerable to data that it receives from untrusted sources, which includes DNS. To provide partial protection to internal, unpatched sendmail MTAs, 8.12.9 changes by default (char)0xff to (char)0x7f in headers etc. To turn off this conversion compile with -DALLOW_255 or use the command line option -d82.101. To provide partial protection for internal, unpatched MTAs that may be performing 7->8 or 8->7 bit MIME conversions, the default for MaxMimeHeaderLength has been changed to 2048/1024. Note: this does have a performance impact, and it only protects against frontal attacks from the outside. To disable the checks and return to pre-8.12.9 defaults, set MaxMimeHeaderLength to 0/0. Do not complain about -ba when submitting mail. Problem noted by Derek Wueppelmann. Fix compilation with Berkeley DB 1.85 on systems that do not have flock(2). Problem noted by Andy Harper of Kings College London. Properly initialize data structure for dns maps to avoid various errors, e.g., looping processes. Problem noted by Mauri
Sendmail exploit
Hi, hadn't seen this mentioned on list. Forwarded from Bugtraq. Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED] ICQ: 104781119 Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- Forwarded message -- CVE: CAN-2003-0161 CERT: VU#897604 *** FORCED RELEASE -- VENDOR NOTIFIED AS OF 03/18/03 *** There is a vulnerability in Sendmail versions 8.12.8 and prior. The address parser performs insufficient bounds checking in certain conditions due to a char to int conversion, making it possible for an attacker to take control of the application. This problem is not related to the recent ISS vulnerability announcement. The impact is believed to be a root compromise. I've confirmed this is a local issue, and my initial impression is that a remote attack possibility is not that unlikely. Only platforms with 'char' type signed by default are vulnerable as-is, and little endian systems would be easier to exploit. Systems that use Sendmail privilege separation are safer against the _local_ attack, but even then it is still possible to compromise the smmsp account and control the submission queue. The bug lurks in parseaddr.c in prescan() function, which, in certain conditions, will run past the buffer size limit and overwrite stack variables, reaching to and past the stored instruction pointer itself. This function is called quite generously accross the code for processing e-mail addresses. It is possible for the attacker to repeatedly skip the length check location in this function because of an unfortunate construction of a "special" control value check. A special value, NOCHAR, is defined as -1. There is a variable 'c', also used to store last read character, declared as int, and the variable will be sometimes assigned the value of NOCHAR to indicate a special condition. Unfortunately, the input character - type char - defaults to a signed type on many modern platforms, and ASCII value 0xff ((char)-1) will be converted to 0x ((int)-1) upon assignment. This makes character 0xff indistinguishable from NOCHAR after being stored in 'c', and makes it possible for the attacker to spoof NOCHAR and skip the length check. Since precise control of the overwrite process is possible (length, offset and layout are up to the attacker), even though the values are mostly fixed, it is reasonable to expect that this vulnerability will be easy to exploit on little endian systems. Even on big endian systems, it might be still possible to alter important control variables on the stack, and you are generally advised to upgrade. I've notified the vendor on March 18, and got a response on the next day. Sendmail is releasing version 8.12.9, and the official notice is as follows: Sendmail, Inc., and the Sendmail Consortium announce the availability of sendmail 8.12.9. It contains a fix for a critical security problem discovered by Michal Zalewski whom we thank for bringing this problem to our attention. Sendmail urges all users to either upgrade to sendmail 8.12.9 or apply a patch for your sendmail version. Remember to check the PGP signatures of patches or releases obtained via FTP or HTTP (to check the correctness of the patches in this announcement please verify the PGP signature of it). For those not running the open source version, check with your vendor for a patch. SECURITY: Fix a buffer overflow in address parsing due to a char to int conversion problem which is potentially remotely exploitable. Problem found by Michal Zalewski. Please visit http://www.sendmail.org for more details and patches, and check with your vendor for the availability of a new or patched package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iptables forwarding to inside firewall
On Fri, 28 Mar 2003, Hanasaki JiJi wrote: > Working on running a SMTP server inside the firewall that takes incoming > SMTP traffic from outside the firewall. The below rules are not > working. The firewall refuses connections. Any input on what wrong? There has been quite a bit of discussion on the mechanics of setting up the port redirection to a box inside your firewall. I'd like to mention the potential folly of doing this. By doing a port redirect from from port 25 on your firewall to port 25 on a box inside you are effectively exposing the internal host to the Internet on this port, circumventing your firewall. If a remote exploit is found in the MTA running on your internal host (as has just occured with sendmail again), an attacker may be able to launch a direct attack on this box. Depending on your overall security structure they may then be able to attack any number of hosts behind your firewall. Some of the alteratives aren't much better. Running an MTA on your firewall is just as bad as a remote exploit here may allow an attack access to the root on the firewall, allowing the firewall to be circumvented again. If you have more than 1 static address, an MTA running in a DMZ is definately better. This way you could still have your internal MTA being port forwarded by restrict access through the firewall by source address, such that only your MTA in the DMZ can access the port redirect. If you can restrict access by way of network interface on the firewall[1] then you're much much better off again as this protects against a spoof. [1] If you use the "3 legged firewall" setup, it is possible to distinguish DMZ traffic from other traffic based on which interface it is entering the firewall. This all presupposes you have been allocated a subnet of static addresses by your ISP. If this is for a home setup you may not be able to do much about the security aspect or it may not be worth it to setup a DMZ (this is perfectly valid, it's all about risk assessment), but it's always worth considering the alternatives. Cheers, Rob -- Robert Brockway B.Sc. email: [EMAIL PROTECTED] ICQ: 104781119 Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
