Re: [PHP] safe mode bug ?
On Sun, Jun 06, 2004 at 03:03:00PM +0200, Andreas John wrote: Hi! There are 2.5 possibilities that make sense. a.) mod_suphp [Any volunteers to put that into debian tree??:-)] www.suphp.org I've got preliminary packages for it (with an ITP). I'm going to put it somewhere and I'm able to give it to any DD for integration in debian. -- Emmanuel Lacour Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76 mailto:[EMAIL PROTECTED] -http://www.easter-eggs.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SEARCH attack
Hi, I hoping somebody can both fill me in on what this SEARCH is all about, and what I can/should do to stop it: Every so often I find a very long request in my Apache access logs that seems to be an attempted SEARCH (SEARCH /\x90\x02\xb1\x02\xb1\x02\ ...). 1). Is this a security problem (on a Linux server)? 2). If so, how can I stop this? I tried to stop it using a Limit SEARCH, but a configtest told me that SEARCH was an undefined or unknown method. I placed the Limit SEARCH within the Directory / container as well as out on it's own in the config file. 3). Is this a Windows platform issue? 4). If so, how can I stop these attempts from filling up my access logs. All info is greatly appreciated! Thanks, Robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PHP] safe mode bug ?
Robert Hensel [EMAIL PROTECTED] writes: Hi, I understand that there are a lot of solutions to make PHP more safe. And of course,I don't see safe_mode as _the_ solution. But I definetly consider it to be a good extra protection, just like basedir restrictions, and the problem I described seems simply like a bug in safe_mode. True. I forgot about using it a long time ago.. safe_mode is not a bad idea, but the way it's implemented really IS.. :( Franz Georg Khler wrote: Hello, it is widely known that safe_mode is not really safe. You might want to restrict access with open_basedir . I think open_basedir is far better and safer that the whole safe_mode thing.. The most secure solution is still to install php's cgi executable in an suexec environment. I agree with this, but its not applicable on boxes with heavy load.. CGI cannot meet the speed of php apache module.. Maybe with FastCGI, but I haven't tried yet.. -- regards, = michal panoch - linux admin = [EMAIL PROTECTED] = gpg fp: 816b be10 99cf 159b 8e1a 4648 ad7a 9df2 de4e c6f4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
Hi I have noticed the same here -- have a look at this http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en I liked the rewrite solution to throw it to ms... ;) Michael Robert Cates wrote: Hi, I hoping somebody can both fill me in on what this SEARCH is all about, and what I can/should do to stop it: Every so often I find a very long request in my Apache access logs that seems to be an attempted SEARCH (SEARCH /\x90\x02\xb1\x02\xb1\x02\ ...). 1). Is this a security problem (on a Linux server)? 2). If so, how can I stop this? I tried to stop it using a Limit SEARCH, but a configtest told me that SEARCH was an undefined or unknown method. I placed the Limit SEARCH within the Directory / container as well as out on it's own in the config file. 3). Is this a Windows platform issue? 4). If so, how can I stop these attempts from filling up my access logs. All info is greatly appreciated! Thanks, Robert -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
On Mon, Jun 07, 2004 at 11:42:53 +0200, Robert Cates wrote: I hoping somebody can both fill me in on what this SEARCH is all about, SEARCH is documented in http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.2 It is a part of an internet draft extending the WebDAV protocol (http://www.webdav.org) which extends HTTP with features suitable for authoring and versioning. and what I can/should do to stop it: Every so often I find a very long request in my Apache access logs that seems to be an attempted SEARCH (SEARCH /\x90\x02\xb1\x02\xb1\x02\ ...). 1). Is this a security problem (on a Linux server)? Judging by http://www.snort.org/snort-db/sid.html?sid=1070 it is only really relevant for IIS servers. 2). If so, how can I stop this? I tried to stop it using a Limit SEARCH, but a configtest told me that SEARCH was an undefined or unknown method. Your server doesn't implement the SEARCH method, so the attempted overflow fails. HTH, Ray -- LWN normally tries to avoid talking much about Microsoft - it is simply irrelevant to the free software world most of the time. http://www.lwn.net/2000/0406/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
Thanks much! The rewrite solution looks good to me as well, and I'll add to my config shortly! Thanks again, Robert - Original Message - From: mimo [EMAIL PROTECTED] To: Robert Cates [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 07, 2004 2:36 PM Subject: Re: SEARCH attack Hi I have noticed the same here -- have a look at this http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en I liked the rewrite solution to throw it to ms... ;) Michael Robert Cates wrote: Hi, I hoping somebody can both fill me in on what this SEARCH is all about, and what I can/should do to stop it: Every so often I find a very long request in my Apache access logs that seems to be an attempted SEARCH (SEARCH /\x90\x02\xb1\x02\xb1\x02\ ...). 1). Is this a security problem (on a Linux server)? 2). If so, how can I stop this? I tried to stop it using a Limit SEARCH, but a configtest told me that SEARCH was an undefined or unknown method. I placed the Limit SEARCH within the Directory / container as well as out on it's own in the config file. 3). Is this a Windows platform issue? 4). If so, how can I stop these attempts from filling up my access logs. All info is greatly appreciated! Thanks, Robert -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
Just be aware that it's actual mod_alias rather than mod_rewrite lines in that extract, so the first line should be IfModule mod_alias.c Of course, it will only break due to the error if you don't have mod_rewrite loaded. On Jun 7, 2004, at 11:58 AM, Robert Cates wrote: Thanks much! The rewrite solution looks good to me as well, and I'll add to my config shortly! Thanks again, Robert - Original Message - From: mimo [EMAIL PROTECTED] To: Robert Cates [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 07, 2004 2:36 PM Subject: Re: SEARCH attack Hi I have noticed the same here -- have a look at this http://216.239.59.104/search?q=cache:RA7huHM9tEoJ: forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/ %5Cx90%5Cx02hl=en I liked the rewrite solution to throw it to ms... ;) Michael Robert Cates wrote: Hi, I hoping somebody can both fill me in on what this SEARCH is all about, and what I can/should do to stop it: Every so often I find a very long request in my Apache access logs that seems to be an attempted SEARCH (SEARCH /\x90\x02\xb1\x02\xb1\x02\ ...). 1). Is this a security problem (on a Linux server)? 2). If so, how can I stop this? I tried to stop it using a Limit SEARCH, but a configtest told me that SEARCH was an undefined or unknown method. I placed the Limit SEARCH within the Directory / container as well as out on it's own in the config file. 3). Is this a Windows platform issue? 4). If so, how can I stop these attempts from filling up my access logs. All info is greatly appreciated! Thanks, Robert -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
The only problem I have with using Mod_Rewrite for this sort of thing is if you want to do it to every VirtualHost on your server, and you're a heavy user of Mod_Rewrite, you have to add that entire set to EVERY VirtualHost container, because Mod_Rewrite commands within a VirtualHost container take precedence over those in the main server config. So if you have a RewriteRule ^/.* in a VirtualHost, that virtualHost won't pick up any RewriteRule's in the main config :^( A bummer when you want to use one standard robots.txt file for all sites in your config. As I don't use Mod_Alias for anything else, this seems to be a cleaner way of doing this. Assuming Mod_Alias gets first dibs at the request, of course. :^) On Jun 7, 2004, at 1:43 PM, Yves J. wrote: I think this is even better: IfModule mod_rewrite.c RewriteEngine on # Uncomment these if you want an intrusion log. # RewriteLog /var/log/worms-kiddies.log # RewriteLogLevel 1 RewriteRule ^/(.*)cmd.exe(.*)$ http://sameserver/police.php [L] RewriteRule ^/(.*)root.exe(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/_vti_bin\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/scripts\/\.\.(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/_mem_bin\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/msadc\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/MSADC\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/c\/winnt\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/d\/winnt\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/x90\/(.*)$ http://sameserver/police.php /IfModule sameserver is your server (You could remove that part) police.php is some scary page :-) I think this is better since it wouldn't rely on the HTTP client williness to go to the redirect page, as it happens with a mod_alias sollution. Of course this could all be useless if the hacko is a worm with no fear! Anyway, it's just a funny alternative to a decent IDS. See you, Yves Junqueira - Lynx Informatica www.lynx.com.br Just be aware that it's actual mod_alias rather than mod_rewrite lines in that extract, so the first line should be IfModule mod_alias.c Of course, it will only break due to the error if you don't have mod_rewrite loaded. On Jun 7, 2004, at 11:58 AM, Robert Cates wrote: Thanks much! The rewrite solution looks good to me as well, and I'll add to my config shortly! Thanks again, Robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
I see these all the time myself and to turn the server into a black hole when it comes to exploitable code is a interesting idea. Blocking the NOP operation by blocking x90 does that pretty nicely on its own, however you could also block a jmp/mov instruction if you really wanted to be 'safe', but some users like using hex values for things, so its a trade off since people tend to move to other service providers when they find out there current one doesn't allow the input needed by there favorite script. Perhaps switching 'http://www.microsoft.com' from that howto with 'localhost' would be even more interesting; But from a legal standpoint the water is murky on that scale. - D On 7 Jun 2004 at 16:41, Dena Whitebirch wrote: I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
http://127.0.0.1 On Jun 7, 2004, at 3:41 PM, Dena Whitebirch wrote: I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ: forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/ %5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
You have an interesting point (worry), but one of my rules in life is that if I can prove my innocence, I really don't worry much. I would hate to have to go through the hassle though. 8-) I don't know if the RedirectMatch would trace back to my server/IP, or to the original requester. Can anybody answer that, with absolute sureness? Robert - Original Message - From: Dena Whitebirch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 07, 2004 10:41 PM Subject: Re: SEARCH attack I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
OK, you've gone beyond me. What do you mean by blocking the NOP operation or jmp/mov instruction? How would you do this with an Apache server on a Linux platform? Also, wouldn't replacing the www.microsoft.com with localhost (or http://127.0.0.1/) just send the request right back to my own server, probably even putting it in a loop? Robert - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 07, 2004 11:01 PM Subject: Re: SEARCH attack I see these all the time myself and to turn the server into a black hole when it comes to exploitable code is a interesting idea. Blocking the NOP operation by blocking x90 does that pretty nicely on its own, however you could also block a jmp/mov instruction if you really wanted to be 'safe', but some users like using hex values for things, so its a trade off since people tend to move to other service providers when they find out there current one doesn't allow the input needed by there favorite script. Perhaps switching 'http://www.microsoft.com' from that howto with 'localhost' would be even more interesting; But from a legal standpoint the water is murky on that scale. - D On 7 Jun 2004 at 16:41, Dena Whitebirch wrote: I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
On Tue, Jun 08, 2004 at 01:07:32AM +0200, Robert Cates wrote: OK, you've gone beyond me. What do you mean by blocking the NOP operation or jmp/mov instruction? How would you do this with an Apache server on a Linux platform? Presumably meaning that you'd use a rule to block the value '0x90' (That's 90 in hex) anywhere within an URL. This is because the 0x90 byte is the value for the NOP instruction on the x86 platform and is common in exploits. It's unlikely to ever occur in a legitimate request so it seems like a simple thing to do. However if you're going to do that you might as well go the whole hog and just install 'mod_security' for Apache which will allow you to filter values passed to scripts (POST / GET) as well. Also, wouldn't replacing the www.microsoft.com with localhost (or http://127.0.0.1/) just send the request right back to my own server, probably even putting it in a loop? The desired affect is that it would redirect to the requestors machine. As the attacker fetches a page, and recives a redirect response it should then go off and request it. So sending out a 127.0.0.1 response should make it request a page from its own machine. However these redirects are largely pointless. Most of the worms that I've ever been hit with have ignored the redirect request anyway. So you've not achived anything. It'd be simple to test this; find a machine which is getting repeatedly hit by one of these requests and see if you can redirect it to somewhere else on your server - testing if it worked by looking at your access log. I'd be suprised if it did. Really this kind of stuff, whilst annoying and irritating in many ways, is just background noise on todays internet. Patch your boxes, and ignore exploit attempts that affect other platforms. Steve -- # The Debian Security Audit Project. http://www.debian.org/security/audit -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
Sorry, I have coding way too much php, so to me the 'localhost' in single quests means the absolute string, not the string as a variable to be parsed; In short I was saying that it would be interesting to send out a 'Location: ' redirect to get them to look at themselves (there own localhost, as in there own ip), Sorry if I was unclear. As for NOP/JMP/MOV, these are all assembly instructions that are pretty much standard across different computer hardware architectures/platforms; Most exploits these days ask for one of two things, a simple string like a file path (in the case that the httpd does not handle malformed paths correctly) or a hex encoded string (like that big long line in your logfile) that is usually translated into the raw hexadecimal by the server itself; Since exploits need to run code on the remote host to work, they must inject this assembly code in some form, and the hex that you see in your log files is in fact this assembly code. By blocking these common hex values that translate into rouge assembly code, you can in effect block these exploits from working to some extent if not completely; But as I said it is a trade off, since every thing you block take away from the possible ipout that can be used by your servers (and thus your customers) scripts. I hope that clears things up, if not just say so. - D On 8 Jun 2004 at 1:07, Robert Cates wrote: OK, you've gone beyond me. What do you mean by blocking the NOP operation or jmp/mov instruction? How would you do this with an Apache server on a Linux platform? Also, wouldn't replacing the www.microsoft.com with localhost (or http://127.0.0.1/) just send the request right back to my own server, probably even putting it in a loop? Robert - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 07, 2004 11:01 PM Subject: Re: SEARCH attack I see these all the time myself and to turn the server into a black hole when it comes to exploitable code is a interesting idea. Blocking the NOP operation by blocking x90 does that pretty nicely on its own, however you could also block a jmp/mov instruction if you really wanted to be 'safe', but some users like using hex values for things, so its a trade off since people tend to move to other service providers when they find out there current one doesn't allow the input needed by there favorite script. Perhaps switching 'http://www.microsoft.com' from that howto with 'localhost' would be even more interesting; But from a legal standpoint the water is murky on that scale. - D On 7 Jun 2004 at 16:41, Dena Whitebirch wrote: I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: SEARCH attack
8 Really this kind of stuff, whilst annoying and irritating in many ways, is just background noise on todays internet. Patch your boxes, and ignore exploit attempts that affect other platforms. Steve 8 I have to agree, a handful of years ago when I started on line I used to report, such stuff, I learned, 1) Looking for admin emails in DNS for a zone etc, shows that 50% or more are wrong. 2) 99% of the remainder never replied, and appeared to do nothing if they did receive it. 3) Their ISP's didn't care either. 4) The remaining didn't know how to fix, or just threw abuse back. So mostly your just wasting your time, Windows boxes will be and will continue to be hacked left right and centre. Joe Dumb will continue to put their as is wee home based XP, win2k (even Linux now) web server on the end of their ADSL/cable so that people can look at family pictures with no clue beyond, hey it works isn't it neat. So for the foreseeable future propagation of worms, Trojans and spam relays will continue to exist and multiply. just ignore it and get on with your life. regards thing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
Well technically the bot would be the one making the request, your just telling it to make it; no connection would in fact be made between your server and the one you are redirecting it to. The issue is simple in legal terms; your telling them what to do in response to there actions, now do they have the legal right to try to exploit your server? Not usually, so I personally believe that under the law your server would only be guilty of trying to defend itself from a unprovoked attack, but then again I am a computer nerd not a lawyer so Im not a expert on the law. Interesting thought, however, as the idea that a computer can defend itself leads to all sorts of interesting ideas no doubt full of blasphemy, libel and slander against more then a few core human conceptions.. but alas that is a different topic, and not meant for this thread. -D On 8 Jun 2004 at 1:00, Robert Cates wrote: You have an interesting point (worry), but one of my rules in life is that if I can prove my innocence, I really don't worry much. I would hate to have to go through the hassle though. 8-) I don't know if the RedirectMatch would trace back to my server/IP, or to the original requester. Can anybody answer that, with absolute sureness? Robert - Original Message - From: Dena Whitebirch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 07, 2004 10:41 PM Subject: Re: SEARCH attack I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PHP] safe mode bug ?
On Sun, Jun 06, 2004 at 03:03:00PM +0200, Andreas John wrote: Hi! There are 2.5 possibilities that make sense. a.) mod_suphp [Any volunteers to put that into debian tree??:-)] www.suphp.org I've got preliminary packages for it (with an ITP). I'm going to put it somewhere and I'm able to give it to any DD for integration in debian. -- Emmanuel Lacour Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76 mailto:[EMAIL PROTECTED] -http://www.easter-eggs.com
SEARCH attack
Hi, I hoping somebody can both fill me in on what this SEARCH is all about, and what I can/should do to stop it: Every so often I find a very long request in my Apache access logs that seems to be an attempted SEARCH (SEARCH /\x90\x02\xb1\x02\xb1\x02\ ...). 1). Is this a security problem (on a Linux server)? 2). If so, how can I stop this? I tried to stop it using a Limit SEARCH, but a configtest told me that SEARCH was an undefined or unknown method. I placed the Limit SEARCH within the Directory / container as well as out on it's own in the config file. 3). Is this a Windows platform issue? 4). If so, how can I stop these attempts from filling up my access logs. All info is greatly appreciated! Thanks, Robert
Re: [PHP] safe mode bug ?
Robert Hensel [EMAIL PROTECTED] writes: Hi, I understand that there are a lot of solutions to make PHP more safe. And of course,I don't see safe_mode as _the_ solution. But I definetly consider it to be a good extra protection, just like basedir restrictions, and the problem I described seems simply like a bug in safe_mode. True. I forgot about using it a long time ago.. safe_mode is not a bad idea, but the way it's implemented really IS.. :( Franz Georg Khler wrote: Hello, it is widely known that safe_mode is not really safe. You might want to restrict access with open_basedir . I think open_basedir is far better and safer that the whole safe_mode thing.. The most secure solution is still to install php's cgi executable in an suexec environment. I agree with this, but its not applicable on boxes with heavy load.. CGI cannot meet the speed of php apache module.. Maybe with FastCGI, but I haven't tried yet.. -- regards, = michal panoch - linux admin = [EMAIL PROTECTED] = gpg fp: 816b be10 99cf 159b 8e1a 4648 ad7a 9df2 de4e c6f4
Re: SEARCH attack
Hi I have noticed the same here -- have a look at this http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en I liked the rewrite solution to throw it to ms... ;) Michael Robert Cates wrote: Hi, I hoping somebody can both fill me in on what this SEARCH is all about, and what I can/should do to stop it: Every so often I find a very long request in my Apache access logs that seems to be an attempted SEARCH (SEARCH /\x90\x02\xb1\x02\xb1\x02\ ...). 1). Is this a security problem (on a Linux server)? 2). If so, how can I stop this? I tried to stop it using a Limit SEARCH, but a configtest told me that SEARCH was an undefined or unknown method. I placed the Limit SEARCH within the Directory / container as well as out on it's own in the config file. 3). Is this a Windows platform issue? 4). If so, how can I stop these attempts from filling up my access logs. All info is greatly appreciated! Thanks, Robert -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE.
Re: SEARCH attack
On Mon, Jun 07, 2004 at 11:42:53 +0200, Robert Cates wrote: I hoping somebody can both fill me in on what this SEARCH is all about, SEARCH is documented in http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.2 It is a part of an internet draft extending the WebDAV protocol (http://www.webdav.org) which extends HTTP with features suitable for authoring and versioning. and what I can/should do to stop it: Every so often I find a very long request in my Apache access logs that seems to be an attempted SEARCH (SEARCH /\x90\x02\xb1\x02\xb1\x02\ ...). 1). Is this a security problem (on a Linux server)? Judging by http://www.snort.org/snort-db/sid.html?sid=1070 it is only really relevant for IIS servers. 2). If so, how can I stop this? I tried to stop it using a Limit SEARCH, but a configtest told me that SEARCH was an undefined or unknown method. Your server doesn't implement the SEARCH method, so the attempted overflow fails. HTH, Ray -- LWN normally tries to avoid talking much about Microsoft - it is simply irrelevant to the free software world most of the time. http://www.lwn.net/2000/0406/
Re: SEARCH attack
Thanks much! The rewrite solution looks good to me as well, and I'll add to my config shortly! Thanks again, Robert - Original Message - From: mimo [EMAIL PROTECTED] To: Robert Cates [EMAIL PROTECTED] Cc: debian-isp@lists.debian.org Sent: Monday, June 07, 2004 2:36 PM Subject: Re: SEARCH attack Hi I have noticed the same here -- have a look at this http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en I liked the rewrite solution to throw it to ms... ;) Michael Robert Cates wrote: Hi, I hoping somebody can both fill me in on what this SEARCH is all about, and what I can/should do to stop it: Every so often I find a very long request in my Apache access logs that seems to be an attempted SEARCH (SEARCH /\x90\x02\xb1\x02\xb1\x02\ ...). 1). Is this a security problem (on a Linux server)? 2). If so, how can I stop this? I tried to stop it using a Limit SEARCH, but a configtest told me that SEARCH was an undefined or unknown method. I placed the Limit SEARCH within the Directory / container as well as out on it's own in the config file. 3). Is this a Windows platform issue? 4). If so, how can I stop these attempts from filling up my access logs. All info is greatly appreciated! Thanks, Robert -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE.
Re: SEARCH attack
Just be aware that it's actual mod_alias rather than mod_rewrite lines in that extract, so the first line should be IfModule mod_alias.c Of course, it will only break due to the error if you don't have mod_rewrite loaded. On Jun 7, 2004, at 11:58 AM, Robert Cates wrote: Thanks much! The rewrite solution looks good to me as well, and I'll add to my config shortly! Thanks again, Robert - Original Message - From: mimo [EMAIL PROTECTED] To: Robert Cates [EMAIL PROTECTED] Cc: debian-isp@lists.debian.org Sent: Monday, June 07, 2004 2:36 PM Subject: Re: SEARCH attack Hi I have noticed the same here -- have a look at this http://216.239.59.104/search?q=cache:RA7huHM9tEoJ: forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/ %5Cx90%5Cx02hl=en I liked the rewrite solution to throw it to ms... ;) Michael Robert Cates wrote: Hi, I hoping somebody can both fill me in on what this SEARCH is all about, and what I can/should do to stop it: Every so often I find a very long request in my Apache access logs that seems to be an attempted SEARCH (SEARCH /\x90\x02\xb1\x02\xb1\x02\ ...). 1). Is this a security problem (on a Linux server)? 2). If so, how can I stop this? I tried to stop it using a Limit SEARCH, but a configtest told me that SEARCH was an undefined or unknown method. I placed the Limit SEARCH within the Directory / container as well as out on it's own in the config file. 3). Is this a Windows platform issue? 4). If so, how can I stop these attempts from filling up my access logs. All info is greatly appreciated! Thanks, Robert -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
The only problem I have with using Mod_Rewrite for this sort of thing is if you want to do it to every VirtualHost on your server, and you're a heavy user of Mod_Rewrite, you have to add that entire set to EVERY VirtualHost container, because Mod_Rewrite commands within a VirtualHost container take precedence over those in the main server config. So if you have a RewriteRule ^/.* in a VirtualHost, that virtualHost won't pick up any RewriteRule's in the main config :^( A bummer when you want to use one standard robots.txt file for all sites in your config. As I don't use Mod_Alias for anything else, this seems to be a cleaner way of doing this. Assuming Mod_Alias gets first dibs at the request, of course. :^) On Jun 7, 2004, at 1:43 PM, Yves J. wrote: I think this is even better: IfModule mod_rewrite.c RewriteEngine on # Uncomment these if you want an intrusion log. # RewriteLog /var/log/worms-kiddies.log # RewriteLogLevel 1 RewriteRule ^/(.*)cmd.exe(.*)$ http://sameserver/police.php [L] RewriteRule ^/(.*)root.exe(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/_vti_bin\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/scripts\/\.\.(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/_mem_bin\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/msadc\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/MSADC\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/c\/winnt\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/d\/winnt\/(.*)$ http://sameserver/police.php RewriteRule ^/(.*)\/x90\/(.*)$ http://sameserver/police.php /IfModule sameserver is your server (You could remove that part) police.php is some scary page :-) I think this is better since it wouldn't rely on the HTTP client williness to go to the redirect page, as it happens with a mod_alias sollution. Of course this could all be useless if the hacko is a worm with no fear! Anyway, it's just a funny alternative to a decent IDS. See you, Yves Junqueira - Lynx Informatica www.lynx.com.br Just be aware that it's actual mod_alias rather than mod_rewrite lines in that extract, so the first line should be IfModule mod_alias.c Of course, it will only break due to the error if you don't have mod_rewrite loaded. On Jun 7, 2004, at 11:58 AM, Robert Cates wrote: Thanks much! The rewrite solution looks good to me as well, and I'll add to my config shortly! Thanks again, Robert
Re: SEARCH attack
I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch
Re: SEARCH attack
I see these all the time myself and to turn the server into a black hole when it comes to exploitable code is a interesting idea. Blocking the NOP operation by blocking x90 does that pretty nicely on its own, however you could also block a jmp/mov instruction if you really wanted to be 'safe', but some users like using hex values for things, so its a trade off since people tend to move to other service providers when they find out there current one doesn't allow the input needed by there favorite script. Perhaps switching 'http://www.microsoft.com' from that howto with 'localhost' would be even more interesting; But from a legal standpoint the water is murky on that scale. - D On 7 Jun 2004 at 16:41, Dena Whitebirch wrote: I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
http://127.0.0.1 On Jun 7, 2004, at 3:41 PM, Dena Whitebirch wrote: I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ: forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/ %5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SEARCH attack
You have an interesting point (worry), but one of my rules in life is that if I can prove my innocence, I really don't worry much. I would hate to have to go through the hassle though. 8-) I don't know if the RedirectMatch would trace back to my server/IP, or to the original requester. Can anybody answer that, with absolute sureness? Robert - Original Message - From: Dena Whitebirch [EMAIL PROTECTED] To: debian-isp@lists.debian.org Sent: Monday, June 07, 2004 10:41 PM Subject: Re: SEARCH attack I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: SEARCH attack
8 Really this kind of stuff, whilst annoying and irritating in many ways, is just background noise on todays internet. Patch your boxes, and ignore exploit attempts that affect other platforms. Steve 8 I have to agree, a handful of years ago when I started on line I used to report, such stuff, I learned, 1) Looking for admin emails in DNS for a zone etc, shows that 50% or more are wrong. 2) 99% of the remainder never replied, and appeared to do nothing if they did receive it. 3) Their ISP's didn't care either. 4) The remaining didn't know how to fix, or just threw abuse back. So mostly your just wasting your time, Windows boxes will be and will continue to be hacked left right and centre. Joe Dumb will continue to put their as is wee home based XP, win2k (even Linux now) web server on the end of their ADSL/cable so that people can look at family pictures with no clue beyond, hey it works isn't it neat. So for the foreseeable future propagation of worms, Trojans and spam relays will continue to exist and multiply. just ignore it and get on with your life. regards thing
Re: SEARCH attack
Well technically the bot would be the one making the request, your just telling it to make it; no connection would in fact be made between your server and the one you are redirecting it to. The issue is simple in legal terms; your telling them what to do in response to there actions, now do they have the legal right to try to exploit your server? Not usually, so I personally believe that under the law your server would only be guilty of trying to defend itself from a unprovoked attack, but then again I am a computer nerd not a lawyer so Im not a expert on the law. Interesting thought, however, as the idea that a computer can defend itself leads to all sorts of interesting ideas no doubt full of blasphemy, libel and slander against more then a few core human conceptions.. but alas that is a different topic, and not meant for this thread. -D On 8 Jun 2004 at 1:00, Robert Cates wrote: You have an interesting point (worry), but one of my rules in life is that if I can prove my innocence, I really don't worry much. I would hate to have to go through the hassle though. 8-) I don't know if the RedirectMatch would trace back to my server/IP, or to the original requester. Can anybody answer that, with absolute sureness? Robert - Original Message - From: Dena Whitebirch [EMAIL PROTECTED] To: debian-isp@lists.debian.org Sent: Monday, June 07, 2004 10:41 PM Subject: Re: SEARCH attack I was getting pounded by these too and am wondering though if it worried anyone else that we might be considered to be attacking Microsoft by doing this rewrite? Might there be a similar way to just 'stop' them like sending them to /dev/null or something? http://216.239.59.104/search?q=cache:RA7huHM9tEoJ:forums.macosxhints.com/showthread.php%3Ft%3D22371+%22SEARCH+/%5Cx90%5Cx02hl=en Regards, Dena A. Whitebirch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
