Re: Kernel 2.4 ioperm
On Thursday 22 May 2003 15:16, Simon Huggins wrote: > On Thu, May 22, 2003 at 01:50:51PM -0600, xbud wrote: > > FYI, http://marc.theaimsgroup.com/?|=linux-kernel&m=105271679705571&w=2 > > You say 2.4 in the subject and it says 2.5 in that report. > > Is 2.4 vulnerable too? > Yes. > In a reduced test on 2.4 ioperm succeeds as a user but I'm reluctant to > actually run the real test program because I don't really want to be > putting arbitrary values in ports :) > Why not? > > Simon. > > -- > Black Cat Networks-( "That's why we like you, Mulder; )- > UK domain, email and web hosting -( your ideas are weirder than ours." )- > http://www.blackcatnetworks.co.uk -( - Byers )- -- -- Orlando Padilla http://www.g0thead.com/xbud.asc "I only drink to make other people interesting" --
Kernel 2.4 ioperm
FYI, http://marc.theaimsgroup.com/?|=linux-kernel&m=105271679705571&w=2 -- -- Orlando Padilla http://www.g0thead.com/xbud.asc "I only drink to make other people interesting" --
Re: Logging User Activity
On Wednesday 14 May 2003 10:23, Nathan E Norman wrote: > On Wed, May 14, 2003 at 03:33:36PM +0100, Michael Parkinson wrote: > > Dear All, > > > > Currently implementing a number of modifications to our internal security > > policies and one addition I am attempting to add is the full logging of > > user activity. > > > > I cannot find any simple way of achieving this within the standard doc's > > and searching the web for "log user activity linux debian" does throw up > > some not particularly useful links, including a package for filtering my > > users output to the FBI, not much good for the UK. > > > > Can anyone point me in the right direction? > > Are you trying to log activity on machines or on the network?\ particularly good question ;) My suggestion would be to consider both. For network logging we can 'argue' about what sniffers/stream-assemblers/system-logging utils are the best so I won't get into it. I would simply use syslog-ng and have everything sent over a tunnel with a signature to avoid spoofing, this would only work if your 'network logging' util is capable of using syslog-ng to save logs. anyway, consider forcing the users to use a certain shell and have the shell log everything the users do a la keystroke granularity. A solution may be to separate your users using what Sebastian suggested grsecurity. Another solution would be to chroot all your users (but I generally think it's more of a pain and would simply piss off most of them). http://www.digitaloffense.net/chrsh/chrsh.c http://www.g0thead.com/chrsh-user-setup.txt -- -- Orlando Padilla http://www.g0thead.com/xbud.asc "I only drink to make other people interesting" --
Re: OpenSSH and debian?
Yes, It's somewhat of a new bug that spawned from the media service advisory on user enumeration via a timing issue if OpenSSH is compiled with PAM support. It's not a remote root per say, but mainly an enumeration weakness. By applying 'nodelay' option for pam_unix.so, this 'feature' is remedied. On Tuesday 06 May 2003 09:47, Diederik de Vries wrote: > Hi there! > > Today I was surfing on SecurityFocus, and saw that there was a hole in > OpenSSH (http://www.securityfocus.com/bid/7482/info/). Debian Potato > uses OpenSSH 3.1 p1, which seems to be exploitable. > > Is this true, am I missing something or what? > > Thanks! > > > Diederik de Vries > Netnation Europe > > Heemraadsingel 188 > 3021 DM Rotterdam > T: +31-10-4776515 > F: +31-10-2440250 -- -- Orlando Padilla http://www.g0thead.com/xbud.asc "I only drink to make other people interesting" --
Re: SSL proxy server
While that is an option, it's probably unfeasable for his wantings. (Unless he's the only one connecting to the server). Anyway a simple stunnel portfoward will do the trick. WebServer listens on port 80 locally. stunnel -r 127.0.0.1:80 -d 443 *Note: A valid server certificate and private key must be installed before issueing that command. On Monday 05 May 2003 10:27, Douglas Blood wrote: > Why don't you just ssh with port forwarding and only have the webserver > listen locally? This will encrypt all the traffic and you wouldn't have to > worry as much about secureity holes in the web server. > > Douglas Blood > -- -- Orlando Padilla http://www.g0thead.com/xbud.asc "I only drink to make other people interesting" --
Re: HELP, my Debian Server was hacked!
tar up your /proc/ directory to save a copy of your kcore - it should have useful information unless he managed to zero out all the memory that was being utilized during the break in. turn the box off but make sure it don't delete crap, watch out for logic bombs or what not. remove the disk and mount it on another box -o ro (read only) and do your analysis there. On Tuesday 22 April 2003 13:00, Christian Könning wrote: > Hello List, > > I hope this is not of topic: > > My private server has been hacked: > debian woody 2.4.18bf2.4 kernel, apache-ssl, samba, squid. > > now my problem: the intruder used a rootkit, i think, cause he deleted > /var/log, symlinked /root/.bash_history > /dev/null, etc. > Is there any way to recover the evidences, e.g. the /var/log/ directory? > (ext2) > > and there three sh processes running as root? Ptrace exploit? > how can i dump this processes to file, to keep this evidence? > > > Thanks for help -- -- Orlando Padilla http://www.g0thead.com/xbud.asc --
Re: Network stress testing
Hi Dale, Stress testing networks can be quite tedious depending on what type of 'real simulation' you have to abide by. If you have a budget take a look at an appliance called 'Flame Thrower' I forget who the vendor is ATM, but it was complete in regaurds to stress testing IDS's. We used it at my old company about 2 years ago, and I'm sure it has been enhanced since. If you have no budget and are just looking for a cheap solution (free opensource tools) then 'wget' for ftp / web traffic and tcpdump + tcpreplay are your friends with -nl options (this breaks real network traffic ofcourse). I wrote several tools about 2 years ago ( I had just started coding then so excuse the poor code heh but they worked for me back then ;) SAT Tools on PacketStorm if you want to look at them. *Note - These are probably not feasable for dns stressing. There are several other network appliances available for generating traffic at controlled speeds, but from my experience "Flame thrower" did quite well for IDS Stress testing as it has an API for integrating new attack simulations and has several modules already included in it. -x On Tuesday 22 April 2003 09:21, Dale Amon wrote: > Would anyone have a recommendation for doing a stress > test of a network? I've got a big show coming up and > I'd like to set up re-produceable test procedures so > I know how things respond under expected real life loads. > > I'm sure I've run across discussions of such tools > but I can't remember any names. > > In particular I'd like to be able to hit a web server > (and the local dns) with n requests/min to ensure > it works, or if not to identify the weak spots. > > I'm doing googles in parallel with this query as > I'm rather under stress testing myself at the > moment, with a fixed deadline...
CORE - Snort stream4 pre-processor Integer Overflow
http://www.coresecurity.com/common/showdoc.php?idx=313&idxseccion=10 This went accross several lists a few days ago, I'm forwarding it in case anyone missed it. -- -- Orlando Padilla http://www.g0thead.com/xbud.asc --
Re: kernel ptrace bug
On Wednesday 19 March 2003 09:18, Martynas Domarkas wrote: > Grsecurity patch can limit ordinary user use ptrace. Can it help avoid > ptrace exploit? > > > Martynas yes for the most part limiting access to /proc/self/exe breaks the exploit. http://www.hardrock.org/kernel/2.4.20/linux-2.4.20-ptrace.patch The patch seems to remove all access to ptrace calls even for root though, I don't see how this _fixes_ anything other than breaking the exploit. didn't look into that much so correct me if I'm wrong. -- -- Orlando Padilla http://www.g0thead.com/xbud.asc --
Re: kernel ptrace bug
On Wednesday 19 March 2003 09:18, Martynas Domarkas wrote: > Grsecurity patch can limit ordinary user use ptrace. Can it help avoid > ptrace exploit? > > > Martynas yes for the most part limiting access to /proc/self/exe breaks the exploit. http://www.hardrock.org/kernel/2.4.20/linux-2.4.20-ptrace.patch The patch seems to remove all access to ptrace calls even for root though, I don't see how this _fixes_ anything other than breaking the exploit. didn't look into that much so correct me if I'm wrong. -- -- Orlando Padilla http://www.g0thead.com/xbud.asc -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ptrace vulnerability?
New one. The attached module seems to block the currently circulating exploit, I didn't write it so don't email me if it breaks your system. On Tuesday 18 March 2003 17:39, Steve Meyer wrote: > Correct me if I am wrong but is the ptrace vulnerability not a fairly old > one. By old I mean like a couple of years. Or is this a completely > different ptrace vulnerability. I know there was info about a ptrace > vulnerability at http://packetstormsecurity.com including the working > exploit code a couple of years ago. > -- -- Orlando Padilla http://www.g0thead.com/xbud.asc "To alcohol! The Cause of AND solution to all of life's problems. Alcohol is a way of life. Alcohol is my way of life, and I aim to keep it." -Homer Simpson -- block_ptrees.tgz Description: application/tgz
Re: ptrace vulnerability?
New one. The attached module seems to block the currently circulating exploit, I didn't write it so don't email me if it breaks your system. On Tuesday 18 March 2003 17:39, Steve Meyer wrote: > Correct me if I am wrong but is the ptrace vulnerability not a fairly old > one. By old I mean like a couple of years. Or is this a completely > different ptrace vulnerability. I know there was info about a ptrace > vulnerability at http://packetstormsecurity.com including the working > exploit code a couple of years ago. > -- -- Orlando Padilla http://www.g0thead.com/xbud.asc "To alcohol! The Cause of AND solution to all of life's problems. Alcohol is a way of life. Alcohol is my way of life, and I aim to keep it." -Homer Simpson -- block_ptrees.tgz Description: application/tgz
Re: asynchronous socket error 10060
Your situation is pretty vague, but my guess would be iptables rule is invalid or just not doing what you want it to do . The reason ftp might still be working through it is because it uses a high port to do the actual file transfer. test your rule with something other than ft protocol nc perhaps =). On Tuesday 04 June 2002 02:29 pm, Listas wrote: > Hi guys, I am having this error "asynchronous socket error 10060" when I > try to get some archives from a socket software who was behind a > iptables firewall(doing redirection port). FTP is working with this > redirection. Anyone know what was happened? > > I configure iptables to redirect some TCP request port to other machine > and enables conectiontrack modules. > > > tks -- --- Orlando Padilla [EMAIL PROTECTED] "I only drink to make other people interesting" www.g0thead.com/xbud.asc --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the case of a stolen notebook
On Wednesday 29 May 2002 04:38 pm, Rauno Linnam?e wrote: > On Wed, May 29, 2002 at 03:37:50AM -0500, xbud wrote: > > On Wednesday 29 May 2002 11:16 am, Rauno Linnamäe wrote: > > > Hello, > > > > > > We are running a Debian (potato) box with Samba as PDC for user > > > authentication and file server for W2k LAN clients. Recently one of our > > > notebooks was stolen. As I can identify all the users who have ever > > > logged in via that notebook, and may have their samba password stored > > > on the machine, I revoked all these passwords. > > > > > > Can any of you think of any other steps I should take to minimise the > > > risk of some black-hat abusing the information stored by W2k against > > > our server/network? > > > > This is no way to think if you're a security geek, but if you want to > > make yourself feel better the person who stole your notebook is a mere > > theif and is incapable of using any information other than > > credit/financial information that can lead again to more theft. > > I am quite aware of that. In fact, I was rather thinking about the > consecutive owner/purchaser of the stolen hardware who might have some > knowledge about computer security. > > > On the other hand, purge the users' login's make a significant change to > > the username converntion since he/she knows what you currently use and > > can use this to his/her advantage for later brute force attacks. > > The username can also often be guessed from e-mail addresses. Besides, I do > employ a "strong" password policy, and several IDS-s, thus brute-forcing > would not be of primary concern. > Brute force attacks can be evasive unders circumstances a patient one may try one password per day for several months in an automated fashion. ( what are the odds eh?) IDS's ? If you have any ssl enabled webservers allowing users to check email remotely or login through say 'mindterm' to an internal machine etc... Will the ids catch that too ? ( you willing to monitor after decryption has occured at the OS side ? ) > > He also knows your internal address space information (ie your Internal > > ip addresses are now 'public),of course that is a significant network > > change if your dealing with several thousand hosts. > > All internal addresses are in the 192.168.x.x address space, thus this is > not highly sensitive information, is it? > This depends on you, evidently you're paranoid or you wouldn't be posting here :), why give out any information regarding your network when it's unnecessary ? But I agree under these circumstances not highly sensitive. > > --- > > Orlando Padilla > > [EMAIL PROTECTED] > > "I only drink to make other people interesting" > > www.g0thead.com/xbud.asc > > --- > > Many thanks, > > Rauno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the case of a stolen notebook
On Wednesday 29 May 2002 11:16 am, Rauno Linnamäe wrote: > Hello, > > We are running a Debian (potato) box with Samba as PDC for user > authentication and file server for W2k LAN clients. Recently one of our > notebooks was stolen. As I can identify all the users who have ever logged > in via that notebook, and may have their samba password stored on the > machine, I revoked all these passwords. > > Can any of you think of any other steps I should take to minimise the risk > of some black-hat abusing the information stored by W2k against our > server/network? This is no way to think if you're a security geek, but if you want to make yourself feel better the person who stole your notebook is a mere theif and is incapable of using any information other than credit/financial information that can lead again to more theft. On the other hand, purge the users' login's make a significant change to the username converntion since he/she knows what you currently use and can use this to his/her advantage for later brute force attacks. He also knows your internal address space information (ie your Internal ip addresses are now 'public),of course that is a significant network change if your dealing with several thousand hosts. > > Regards, > > Rauno -- --- Orlando Padilla [EMAIL PROTECTED] "I only drink to make other people interesting" www.g0thead.com/xbud.asc --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the case of a stolen notebook
On Wednesday 29 May 2002 04:38 pm, Rauno Linnam?e wrote: > On Wed, May 29, 2002 at 03:37:50AM -0500, xbud wrote: > > On Wednesday 29 May 2002 11:16 am, Rauno Linnamäe wrote: > > > Hello, > > > > > > We are running a Debian (potato) box with Samba as PDC for user > > > authentication and file server for W2k LAN clients. Recently one of our > > > notebooks was stolen. As I can identify all the users who have ever > > > logged in via that notebook, and may have their samba password stored > > > on the machine, I revoked all these passwords. > > > > > > Can any of you think of any other steps I should take to minimise the > > > risk of some black-hat abusing the information stored by W2k against > > > our server/network? > > > > This is no way to think if you're a security geek, but if you want to > > make yourself feel better the person who stole your notebook is a mere > > theif and is incapable of using any information other than > > credit/financial information that can lead again to more theft. > > I am quite aware of that. In fact, I was rather thinking about the > consecutive owner/purchaser of the stolen hardware who might have some > knowledge about computer security. > > > On the other hand, purge the users' login's make a significant change to > > the username converntion since he/she knows what you currently use and > > can use this to his/her advantage for later brute force attacks. > > The username can also often be guessed from e-mail addresses. Besides, I do > employ a "strong" password policy, and several IDS-s, thus brute-forcing > would not be of primary concern. > Brute force attacks can be evasive unders circumstances a patient one may try one password per day for several months in an automated fashion. ( what are the odds eh?) IDS's ? If you have any ssl enabled webservers allowing users to check email remotely or login through say 'mindterm' to an internal machine etc... Will the ids catch that too ? ( you willing to monitor after decryption has occured at the OS side ? ) > > He also knows your internal address space information (ie your Internal > > ip addresses are now 'public),of course that is a significant network > > change if your dealing with several thousand hosts. > > All internal addresses are in the 192.168.x.x address space, thus this is > not highly sensitive information, is it? > This depends on you, evidently you're paranoid or you wouldn't be posting here :), why give out any information regarding your network when it's unnecessary ? But I agree under these circumstances not highly sensitive. > > --- > > Orlando Padilla > > [EMAIL PROTECTED] > > "I only drink to make other people interesting" > > www.g0thead.com/xbud.asc > > --- > > Many thanks, > > Rauno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ipchains rules for dmz??
On Wednesday 29 May 2002 11:30 am, Rishi L Khan wrote: > I looked into shorewall. It doesn't support ipchains, but seawall does. > Would you suggest updating to iptables or using seawall? > > Do you think that Linux 2.4.x is stable yet? If so, which version? > The kernel overall I believe is considered stable, I've been using 2.4.18 for sometime now and have had no major problems with it. .17 gave me usb horror but was fixed in 18. The only bug I'd watch for would be the NAT bug found by "cartel-securite.fr" using a patch to nmap which reviels internal ip information. According to their advisory 2.4.4 -> 2.4.19pre6 are vulnerable. > I believe that ipchains can do the job and that linux 2.2.20 is stable. I > don't have experience in 2.4.x kernels yet, but am willing to look into > it if people think that it's as stable as 2.2.20. > > Are there any security issues with the currentversion of ipchains that is > addressed with iptables (I don't mean iptables features like stateful > packet filtering -- I mean security vulnerabilities) > I've stuck with ipchains myself, but for no significant reason other than being lazy =). > -rishi > > On Wed, 29 May 2002, Sami Dalouche wrote: > > > Howabout installing shorewall? (www.shorewall.net) the best iptables > > > > script i have ever seen. > > > > It's not only the best iptables script you've ever seen, but it's also a > > nice high-level configuration tool for everything > > concerning firewalling.. Traffic Shaping, IPSec... > > > > Sam -- --- Orlando Padilla [EMAIL PROTECTED] "I only drink to make other people interesting" www.g0thead.com/xbud.asc --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the case of a stolen notebook
On Wednesday 29 May 2002 11:16 am, Rauno Linnamäe wrote: > Hello, > > We are running a Debian (potato) box with Samba as PDC for user > authentication and file server for W2k LAN clients. Recently one of our > notebooks was stolen. As I can identify all the users who have ever logged > in via that notebook, and may have their samba password stored on the > machine, I revoked all these passwords. > > Can any of you think of any other steps I should take to minimise the risk > of some black-hat abusing the information stored by W2k against our > server/network? This is no way to think if you're a security geek, but if you want to make yourself feel better the person who stole your notebook is a mere theif and is incapable of using any information other than credit/financial information that can lead again to more theft. On the other hand, purge the users' login's make a significant change to the username converntion since he/she knows what you currently use and can use this to his/her advantage for later brute force attacks. He also knows your internal address space information (ie your Internal ip addresses are now 'public),of course that is a significant network change if your dealing with several thousand hosts. > > Regards, > > Rauno -- --- Orlando Padilla [EMAIL PROTECTED] "I only drink to make other people interesting" www.g0thead.com/xbud.asc --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ipchains rules for dmz??
On Wednesday 29 May 2002 11:30 am, Rishi L Khan wrote: > I looked into shorewall. It doesn't support ipchains, but seawall does. > Would you suggest updating to iptables or using seawall? > > Do you think that Linux 2.4.x is stable yet? If so, which version? > The kernel overall I believe is considered stable, I've been using 2.4.18 for sometime now and have had no major problems with it. .17 gave me usb horror but was fixed in 18. The only bug I'd watch for would be the NAT bug found by "cartel-securite.fr" using a patch to nmap which reviels internal ip information. According to their advisory 2.4.4 -> 2.4.19pre6 are vulnerable. > I believe that ipchains can do the job and that linux 2.2.20 is stable. I > don't have experience in 2.4.x kernels yet, but am willing to look into > it if people think that it's as stable as 2.2.20. > > Are there any security issues with the currentversion of ipchains that is > addressed with iptables (I don't mean iptables features like stateful > packet filtering -- I mean security vulnerabilities) > I've stuck with ipchains myself, but for no significant reason other than being lazy =). > -rishi > > On Wed, 29 May 2002, Sami Dalouche wrote: > > > Howabout installing shorewall? (www.shorewall.net) the best iptables > > > > script i have ever seen. > > > > It's not only the best iptables script you've ever seen, but it's also a > > nice high-level configuration tool for everything > > concerning firewalling.. Traffic Shaping, IPSec... > > > > Sam -- --- Orlando Padilla [EMAIL PROTECTED] "I only drink to make other people interesting" www.g0thead.com/xbud.asc --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: zlib && ssh
at this very moment in time yes.. if your zlib is up to date.. there is currently no working exploit for this bug.. but one will popup sooner or later. -xbud On Tuesday 12 March 2002 02:19 pm, Martin Hermanowski wrote: > On bugtraq I read something about openssh being vulnerable to the > doube-free bug. > > On my woody boxes, I installed the updated zlib1g from unstable and > restarted sshd. Is this enough to be protected? > > Yours, > Martin
Re: zlib && ssh
at this very moment in time yes.. if your zlib is up to date.. there is currently no working exploit for this bug.. but one will popup sooner or later. -xbud On Tuesday 12 March 2002 02:19 pm, Martin Hermanowski wrote: > On bugtraq I read something about openssh being vulnerable to the > doube-free bug. > > On my woody boxes, I installed the updated zlib1g from unstable and > restarted sshd. Is this enough to be protected? > > Yours, > Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: Exim 3.34 and lower (fwd)
Not sure if this made to this list. I haven't confirmed the following, but thought it was worth forwarding. -xbud -- Forwarded Message -- Subject: Exim 3.34 and lower (fwd) Date: Wed, 13 Feb 2002 11:19:49 -0700 (MST) From: Dave Ahmad <[EMAIL PROTECTED]> To: bugtraq@securityfocus.com Moderator note: I have not had the time to look at the Exim source to verify that these exist and that the attached fix is not broken. Dave Ahmad SecurityFocus www.securityfocus.com -- Forwarded message -- Return-Path: <[EMAIL PROTECTED]> Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 32260 invoked from network); 13 Feb 2002 08:49:23 - Received: from mail.securityfocus.com (HELO securityfocus.com) (66.38.151.9) by lists.securityfocus.com with SMTP; 13 Feb 2002 08:49:23 - Received: (qmail 20929 invoked by alias); 13 Feb 2002 08:50:32 - Received: (qmail 20925 invoked from network); 13 Feb 2002 08:50:31 - Received: from unknown (HELO 2xs.co.il) (212.68.128.50) by mail.securityfocus.com with SMTP; 13 Feb 2002 08:50:31 - Received: from security.2xss.com ([212.68.128.10] helo=2xss.com ident=root) by 2xs.co.il with esmtp id 16avBe-0003GM-00 for bugtraq@securityfocus.com; Wed, 13 Feb 2002 10:54:46 +0200 Sender: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2002 10:44:02 +0200 From: Ehud Tenenbaum <[EMAIL PROTECTED]> Organization: 2xs LTD. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.16-pre1 i686) X-Accept-Language: en MIME-Version: 1.0 To: bugtraq@securityfocus.com Subject: Exim 3.34 and lower Content-Type: multipart/mixed; boundary="C2FFD0A39E3737A0A718E02C" Hey, Its a good time to announce that 2xs security LTD. decided to create a research team in order to focus on finding new bugs, further more we managed to develop a security tool to discover bugs/security flaws. In the near future, the tool itself will became an open source project. Its looks like there is few insecure/lame programming in exim mail server up to current version. first lets take a look at the file: [2xs:root:~] ls -la /usr/exim/bin/exim -rws--x--x1 root root 2061186 Oct 23 12:56 /usr/exim/bin/exim* [2xs:root:~] Suid goodie. [2xs:w00p:/root] id uid=1001(w00p) gid=100(users) groups=100(users) [2xs:w00p:/root] /usr/exim/bin/exim -F `perl -e' print "A" x 32770'` -C `perl -e' print "A" x 32768'` Segmentation fault [2xs:w00p:/root] Many other argument should work as well (as long there is -C among them) [2xs:root:~] gdb /usr/exim/bin/exim GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-slackware-linux"... (gdb) r -F `perl -e' print "A" x 32770'` -C `perl -e' print "A" x 32768'` Starting program: /usr/exim/bin/exim -F `perl -e' print "A" x 32770'` -C `perl -e' print "A" x 32768'` Program received signal SIGSEGV, Segmentation fault. strcpy (dest=0x820e208 'A' ..., src=0xbfff7b48 'A' ...) at ../sysdeps/generic/strcpy.c:40 40 ../sysdeps/generic/strcpy.c: No such file or directory. (gdb) info registers eax0x48216641 1210148417 ecx0x482166bf 1210148543 edx0xbfffa941 -1073764031 ebx0xbffef8d4 -1073809196 esp0xbffeeefc 0xbffeeefc ebp0xbffeef00 0xbffeef00 esi0x820e208136372744 edi0x3 3 eip0x401690e4 0x401690e4 eflags 0x10286 66182 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x0 0 fctrl 0x37f895 fstat 0x0 0 ftag 0x 65535 fiseg 0x23 35 fioff 0x4009ca84 1074383492 foseg 0x2b 43 fooff 0x400fa440 1074766912 fop0x49b1179 after short debugging we found that there is no overflow since the eip register coredumped in the code segment and not in the data segment, yet we believe that there might be a way to exploit this bug with log_write(), we are not going to deliver a working exploit until the vendor will research and fix this bug. We provide a patch to version 3.34 that should solve this bug. In version 3.21 and lower there is another small bug with -t flag again non exploitable just bad programming. This bug was found by The Analyzer, Izik and Mixter. 2xs security research team. should an
Fwd: Exim 3.34 and lower (fwd)
Not sure if this made to this list. I haven't confirmed the following, but thought it was worth forwarding. -xbud -- Forwarded Message -- Subject: Exim 3.34 and lower (fwd) Date: Wed, 13 Feb 2002 11:19:49 -0700 (MST) From: Dave Ahmad <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Moderator note: I have not had the time to look at the Exim source to verify that these exist and that the attached fix is not broken. Dave Ahmad SecurityFocus www.securityfocus.com -- Forwarded message -- Return-Path: <[EMAIL PROTECTED]> Delivered-To: moderator for [EMAIL PROTECTED] Received: (qmail 32260 invoked from network); 13 Feb 2002 08:49:23 - Received: from mail.securityfocus.com (HELO securityfocus.com) (66.38.151.9) by lists.securityfocus.com with SMTP; 13 Feb 2002 08:49:23 - Received: (qmail 20929 invoked by alias); 13 Feb 2002 08:50:32 - Received: (qmail 20925 invoked from network); 13 Feb 2002 08:50:31 - Received: from unknown (HELO 2xs.co.il) (212.68.128.50) by mail.securityfocus.com with SMTP; 13 Feb 2002 08:50:31 - Received: from security.2xss.com ([212.68.128.10] helo=2xss.com ident=root) by 2xs.co.il with esmtp id 16avBe-0003GM-00 for [EMAIL PROTECTED]; Wed, 13 Feb 2002 10:54:46 +0200 Sender: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2002 10:44:02 +0200 From: Ehud Tenenbaum <[EMAIL PROTECTED]> Organization: 2xs LTD. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.16-pre1 i686) X-Accept-Language: en MIME-Version: 1.0 To: [EMAIL PROTECTED] Subject: Exim 3.34 and lower Content-Type: multipart/mixed; boundary="C2FFD0A39E3737A0A718E02C" Hey, Its a good time to announce that 2xs security LTD. decided to create a research team in order to focus on finding new bugs, further more we managed to develop a security tool to discover bugs/security flaws. In the near future, the tool itself will became an open source project. Its looks like there is few insecure/lame programming in exim mail server up to current version. first lets take a look at the file: [2xs:root:~] ls -la /usr/exim/bin/exim -rws--x--x1 root root 2061186 Oct 23 12:56 /usr/exim/bin/exim* [2xs:root:~] Suid goodie. [2xs:w00p:/root] id uid=1001(w00p) gid=100(users) groups=100(users) [2xs:w00p:/root] /usr/exim/bin/exim -F `perl -e' print "A" x 32770'` -C `perl -e' print "A" x 32768'` Segmentation fault [2xs:w00p:/root] Many other argument should work as well (as long there is -C among them) [2xs:root:~] gdb /usr/exim/bin/exim GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-slackware-linux"... (gdb) r -F `perl -e' print "A" x 32770'` -C `perl -e' print "A" x 32768'` Starting program: /usr/exim/bin/exim -F `perl -e' print "A" x 32770'` -C `perl -e' print "A" x 32768'` Program received signal SIGSEGV, Segmentation fault. strcpy (dest=0x820e208 'A' ..., src=0xbfff7b48 'A' ...) at ../sysdeps/generic/strcpy.c:40 40 ../sysdeps/generic/strcpy.c: No such file or directory. (gdb) info registers eax0x48216641 1210148417 ecx0x482166bf 1210148543 edx0xbfffa941 -1073764031 ebx0xbffef8d4 -1073809196 esp0xbffeeefc 0xbffeeefc ebp0xbffeef00 0xbffeef00 esi0x820e208136372744 edi0x3 3 eip0x401690e4 0x401690e4 eflags 0x10286 66182 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x0 0 fctrl 0x37f895 fstat 0x0 0 ftag 0x 65535 fiseg 0x23 35 fioff 0x4009ca84 1074383492 foseg 0x2b 43 fooff 0x400fa440 1074766912 fop0x49b1179 after short debugging we found that there is no overflow since the eip register coredumped in the code segment and not in the data segment, yet we believe that there might be a way to exploit this bug with log_write(), we are not going to deliver a working exploit until the vendor will research and fix this bug. We provide a patch to version 3.34 that should solve this bug. In version 3.21 and lower there is another small bug with -t flag again non exploitable just bad programming. This bug was found by The Analyzer, Izik and Mixter. 2xs security research team. should anyone have questions or
Re: sending password in the command line
This will not work I believe ps aux will show the environment variable's value instead of the variable. Which in your case would be the password, rendering your idea bad! =/ I would chroot the users' environments (jail them) so that they can only see their own processes... of course this might not be the solution you are looking for. -xbud On Thursday 27 December 2001 09:27 am, Pedro Zorzenon Neto wrote: > Hi Friends, > > I am developing a software to provide access control to users of a > network. > The gateway has ipchains rules to DENY packets from all 192.168.0.0/16 > hosts to the 0.0.0.0/0 world. > > If the user (a regular user, not root) does: > >$ myprogram enable username password IP > > the program checks the password in a internal database, and enable > packets from the given IP to the 0/0 world. It also logs user/ip/date. > > if the user does: > >$ myprogram disable username password IP > > it disables the ipchains rules that were enabled before. > > The program seems to be working well. > > Now, here is my question: > > - everybody can capture the passwords with a "ps aux" command, ok? > > - what about doing this to prevent simple ps aux "sniff" > > $ PASS="password" myprogram enable username IP > > then "myprogram" will read the PASS from the environment. > is there anyway a regular user could capture passwords? > > > Thanks in advance, > > Pedro
Re: sending password in the command line
This will not work I believe ps aux will show the environment variable's value instead of the variable. Which in your case would be the password, rendering your idea bad! =/ I would chroot the users' environments (jail them) so that they can only see their own processes... of course this might not be the solution you are looking for. -xbud On Thursday 27 December 2001 09:27 am, Pedro Zorzenon Neto wrote: > Hi Friends, > > I am developing a software to provide access control to users of a > network. > The gateway has ipchains rules to DENY packets from all 192.168.0.0/16 > hosts to the 0.0.0.0/0 world. > > If the user (a regular user, not root) does: > >$ myprogram enable username password IP > > the program checks the password in a internal database, and enable > packets from the given IP to the 0/0 world. It also logs user/ip/date. > > if the user does: > >$ myprogram disable username password IP > > it disables the ipchains rules that were enabled before. > > The program seems to be working well. > > Now, here is my question: > > - everybody can capture the passwords with a "ps aux" command, ok? > > - what about doing this to prevent simple ps aux "sniff" > > $ PASS="password" myprogram enable username IP > > then "myprogram" will read the PASS from the environment. > is there anyway a regular user could capture passwords? > > > Thanks in advance, > > Pedro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NIC losts promisc. mode
Are both NIC's the same ? There's obviously a problem with the second NIC card, perhaps the driver is not very well supported or it's just flaky (dieing =( ). If buying a new one isn't an option, switch it out for the third 'control' card you have since you won't be monitoring a heavy load there. g'luck -xbud
Re: NIC losts promisc. mode
Are both NIC's the same ? There's obviously a problem with the second NIC card, perhaps the driver is not very well supported or it's just flaky (dieing =( ). If buying a new one isn't an option, switch it out for the third 'control' card you have since you won't be monitoring a heavy load there. g'luck -xbud -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
It's speading nicely.
'Nicely' probably isn't a prefered word but you all know what I mean. Here are some numbers. - Snip - [EMAIL PROTECTED]:~$ cat /var/log/boa/access_log | grep /default.ida | cut -f1-4 -d ' ' bla.bla.bla.bla - - [19/Jul/2001:16:18:23bla.bla.bla.bla - - [19/Jul/2001:16:48:16bla.bla.bla.bla - - [19/Jul/2001:16:48:33bla.bla.bla.bla - - [19/Jul/2001:18:00:43bla.bla.bla.bla - - [19/Jul/2001:19:04:32bla.bla.bla.bla - - [19/Jul/2001:19:04:40bla.bla.bla.bla - - [19/Jul/2001:19:34:29bla.bla.bla.bla - - [19/Jul/2001:19:40:50bla.bla.bla.bla - - [19/Jul/2001:20:24:06bla.bla.bla.bla - - [19/Jul/2001:20:42:16bla.bla.bla.bla - - [19/Jul/2001:20:44:54bla.bla.bla.bla - - [19/Jul/2001:20:48:27bla.bla.bla.bla - - [19/Jul/2001:21:26:38bla.bla.bla.bla - - [19/Jul/2001:21:52:57bla.bla.bla.bla - - [19/Jul/2001:22:02:56bla.bla.bla.bla - - [19/Jul/2001:22:58:22bla.bla.bla.bla - - [19/Jul/2001:23:16:19bla.bla.bla.bla - - [19/Jul/2001:23:30:11bla.bla.bla.bla3 - - [19/Jul/2001:23:50:31 [EMAIL PROTECTED]:~$ cat /var/log/boa/access_log | grep /default.ida | cut -f1-4 -d ' ' | wc -l 19 [EMAIL PROTECTED]:~$ --- Snip - I cut the actual attack out cause it gets lengthy and the IPs are blocked for obvious reasons, I also noticed none of the IP's were duplicates. Note all of them are in one day time span... =) I contacted as many of the Company's I could using their IP block. - xbud
It's speading nicely.
'Nicely' probably isn't a prefered word but you all know what I mean. Here are some numbers. - Snip ----- xbud@natas:~$ cat /var/log/boa/access_log | grep /default.ida | cut -f1-4 -d ' ' bla.bla.bla.bla - - [19/Jul/2001:16:18:23bla.bla.bla.bla - - [19/Jul/2001:16:48:16bla.bla.bla.bla - - [19/Jul/2001:16:48:33bla.bla.bla.bla - - [19/Jul/2001:18:00:43bla.bla.bla.bla - - [19/Jul/2001:19:04:32bla.bla.bla.bla - - [19/Jul/2001:19:04:40bla.bla.bla.bla - - [19/Jul/2001:19:34:29bla.bla.bla.bla - - [19/Jul/2001:19:40:50bla.bla.bla.bla - - [19/Jul/2001:20:24:06bla.bla.bla.bla - - [19/Jul/2001:20:42:16bla.bla.bla.bla - - [19/Jul/2001:20:44:54bla.bla.bla.bla - - [19/Jul/2001:20:48:27bla.bla.bla.bla - - [19/Jul/2001:21:26:38bla.bla.bla.bla - - [19/Jul/2001:21:52:57bla.bla.bla.bla - - [19/Jul/2001:22:02:56bla.bla.bla.bla - - [19/Jul/2001:22:58:22bla.bla.bla.bla - - [19/Jul/2001:23:16:19bla.bla.bla.bla - - [19/Jul/2001:23:30:11bla.bla.bla.bla3 - - [19/Jul/2001:23:50:31 xbud@natas:~$ cat /var/log/boa/access_log | grep /default.ida | cut -f1-4 -d ' ' | wc -l 19 xbud@natas:~$ --- Snip - I cut the actual attack out cause it gets lengthy and the IPs are blocked for obvious reasons, I also noticed none of the IP's were duplicates. Note all of them are in one day time span... =) I contacted as many of the Company's I could using their IP block. - xbud
Re: DoS prevention techquies.
If I remember correctly mc in has something to do with multicast addresses, it might be to disable forwarding of mc addressed packets. On my system 2.4.4 it's already set to 0. To enable it or even write to it I believe you have to compile the kernel with a CONFIG_MROUTE flag set somewhere. If the values on your box are set to 0... let them be. Unless you are running a routed daemon and need to route mc addressed frames. -xbud -Original Message- From: Vineet Kumar <[EMAIL PROTECTED]> To: debian-security@lists.debian.org Date: Tuesday, July 17, 2001 12:56 AM Subject: Re: DoS prevention techquies. * Stefan Srdic ([EMAIL PROTECTED]) [010716 21:01]: > > What exactly do these paramters do, and should I be toying around with > them? > Sorry for the smarmy repsonse, but the answer to the second question is "at least not until you are able to answer the first question". Too bad I can't help you answer the first question without doing some reading myself... we'll see if somebody beats me to it. Vineet
Re: DoS prevention techquies.
If I remember correctly mc in has something to do with multicast addresses, it might be to disable forwarding of mc addressed packets. On my system 2.4.4 it's already set to 0. To enable it or even write to it I believe you have to compile the kernel with a CONFIG_MROUTE flag set somewhere. If the values on your box are set to 0... let them be. Unless you are running a routed daemon and need to route mc addressed frames. -xbud -Original Message- From: Vineet Kumar <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Tuesday, July 17, 2001 12:56 AM Subject: Re: DoS prevention techquies. * Stefan Srdic ([EMAIL PROTECTED]) [010716 21:01]: > > What exactly do these paramters do, and should I be toying around with > them? > Sorry for the smarmy repsonse, but the answer to the second question is "at least not until you are able to answer the first question". Too bad I can't help you answer the first question without doing some reading myself... we'll see if somebody beats me to it. Vineet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
