FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread Phill
What is "AFAIR"

Regards,
Phill


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Gottfried Szing
Sent: Thursday, 7 April 2005 1:39 AM
To: slug@slug.org.au
Subject: Re: [SLUG] Possible hacker Attempt

hi

> "GET /default.ida?X...(lots of X's)...X
>
%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u
> 9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a
HTTP/1.0"
> 404 300 "-" "-"

isn't that the code red worm? still in the wild?

> "SEARCH /\x90\x02\xb1\.. ("x02\xb1\" repeats hundreds of times)
> .\ x02\xb1\x90\...(repeats hundreds of
> times)...\x90\x90\x90\x90\x90\x90" 414 341 "-" "-"

AFAIR this is an request that uses an exploit of the IIS and webdav
component (unchecked buffer).

but as long as you don't have IIS and windows running, nothing to fear
about. both attacks works with IIS only and can be ignored on apache. they
are just annoying (messing up the logs) but they cannot compromise the
system.

cu

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


smime.p7s
Description: S/MIME cryptographic signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread Phill
I am also curious. How does this attack work? I understand the idea of
filling up a buffer with junk but then

Regards,
Phill


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Gottfried Szing
Sent: Thursday, 7 April 2005 1:39 AM
To: slug@slug.org.au
Subject: Re: [SLUG] Possible hacker Attempt

hi

> "GET /default.ida?X...(lots of X's)...X
>
%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u
> 9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a
HTTP/1.0"
> 404 300 "-" "-"

isn't that the code red worm? still in the wild?

> "SEARCH /\x90\x02\xb1\.. ("x02\xb1\" repeats hundreds of times)
> .\ x02\xb1\x90\...(repeats hundreds of
> times)...\x90\x90\x90\x90\x90\x90" 414 341 "-" "-"

AFAIR this is an request that uses an exploit of the IIS and webdav
component (unchecked buffer).

but as long as you don't have IIS and windows running, nothing to fear
about. both attacks works with IIS only and can be ignored on apache. they
are just annoying (messing up the logs) but they cannot compromise the
system.

cu

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


smime.p7s
Description: S/MIME cryptographic signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread Phill
OK. I did a bit of reading on the subject. Linux can be vulnerable to
buffer overrun attacks can't it? If not, why not?

Regards,
Phill


-Original Message-
From: Howard Lowndes [mailto:[EMAIL PROTECTED]
Sent: Thursday, 7 April 2005 7:30 AM
To: Phill
Cc: slug@slug.org.au
Subject: Re: FW: [SLUG] Possible hacker Attempt



Phill wrote:
> I am also curious. How does this attack work? I understand the idea of
> filling up a buffer with junk but then

As Gottfried said, on Linux it doesn't work, but on IIS it causes a
buffer overflow which then allows uncontrolled access for the exploit -
or something like that - I don't pay btoo much attention to Microsoft
type problems.

>
> Regards,
> Phill
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Gottfried Szing
> Sent: Thursday, 7 April 2005 1:39 AM
> To: slug@slug.org.au
> Subject: Re: [SLUG] Possible hacker Attempt
>
> hi
>
>
>>"GET /default.ida?X...(lots of X's)...X
>>
>
>
%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u
>
>>9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a
>
> HTTP/1.0"
>
>>404 300 "-" "-"
>
>
> isn't that the code red worm? still in the wild?
>
>
>>"SEARCH /\x90\x02\xb1\.. ("x02\xb1\" repeats hundreds of times)
>>.\ x02\xb1\x90\...(repeats hundreds of
>>times)...\x90\x90\x90\x90\x90\x90" 414 341 "-" "-"
>
>
> AFAIR this is an request that uses an exploit of the IIS and webdav
> component (unchecked buffer).
>
> but as long as you don't have IIS and windows running, nothing to fear
> about. both attacks works with IIS only and can be ignored on apache.
they
> are just annoying (messing up the logs) but they cannot compromise the
> system.
>
> cu
>
> --
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
>

--
Howard.
LANNet Computing Associates - Your Linux people <http://lannet.com.au>
--
When you just want a system that works, you choose Linux;
When you want a system that just works, you choose Microsoft.
--
Flatter government, not fatter government;
Get rid of the Australian states.


smime.p7s
Description: S/MIME cryptographic signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread Howard Lowndes

Phill wrote:
I am also curious. How does this attack work? I understand the idea of
filling up a buffer with junk but then
As Gottfried said, on Linux it doesn't work, but on IIS it causes a 
buffer overflow which then allows uncontrolled access for the exploit - 
or something like that - I don't pay btoo much attention to Microsoft 
type problems.

Regards,
Phill
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Gottfried Szing
Sent: Thursday, 7 April 2005 1:39 AM
To: slug@slug.org.au
Subject: Re: [SLUG] Possible hacker Attempt
hi

"GET /default.ida?X...(lots of X's)...X
%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u
9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a
HTTP/1.0"
404 300 "-" "-"

isn't that the code red worm? still in the wild?

"SEARCH /\x90\x02\xb1\.. ("x02\xb1\" repeats hundreds of times)
.\ x02\xb1\x90\...(repeats hundreds of
times)...\x90\x90\x90\x90\x90\x90" 414 341 "-" "-"

AFAIR this is an request that uses an exploit of the IIS and webdav
component (unchecked buffer).
but as long as you don't have IIS and windows running, nothing to fear
about. both attacks works with IIS only and can be ignored on apache. they
are just annoying (messing up the logs) but they cannot compromise the
system.
cu
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
--
Howard.
LANNet Computing Associates - Your Linux people 
--
When you just want a system that works, you choose Linux;
When you want a system that just works, you choose Microsoft.
--
Flatter government, not fatter government;
Get rid of the Australian states.
begin:vcard
fn:Howard Lowndes
n:Lowndes;Howard
org:LANNet Computing Associates
adr:;;PO Box 1174;Lavington;NSW;2641;Australia
email;internet:howard [AT] lowndes [DOT] name
tel;work:02 6040 0222
tel;fax:02 6040 0222
tel;cell:0419 464 430
note:I am heartily sick and tired of telemarketers, therefore I do not answer phone calls which do not present Caller Line Identification, they get flicked to voicemail.  I apologise if this inconveniences you, and I respect your right to not identify yourself, but I also ask that you respect my right to not answer your call if you choose not to identify yourself.  Try dialing 1832 (#32# from mobiles) before the number, to present Caller Line Identification.
x-mozilla-html:FALSE
url:http://www.lannet.com.au
version:2.1
end:vcard

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

RE: FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread Visser, Martin
Unfortunately a buffer-overflow is not only a Microsoft problem. 

In simple terms, it occurs where an attacker is able to exploit a
programming flaw that allows a program to accept more data then it is
really designed for. Most programs that accept input from the network
(or other input device) will prepare a buffer, some memory space, to
accept that input. If the program is written correctly it should
validate the input or use other some mechnanism to ensure the input does
not exceed the size of the allocated buffer. However, in certain program
architectures, data that is accepted which is more than the buffer can
handle could overwrite existing program data. If this excess data is
craftily designed,  the program can be "tricked" to then execute this
excess data (which is now not just data, but now part of the compromised
programs instructions) and will run with the priveleges of the exploited
program. The excess data is a small chunk of compiled code specifically
designed to run on the target platform - it is usually caused by
inserting a "jump" in the normal code instructions.

In the Code Red example below the attacker is sending a GET request to a
web server. In a vulnerable IIS web server, the URL specified in the
request is much larger than it expected. This data ends up in the web
servers running program space, and is executed by the target system.
The Code Red worm can then do it's job to continue to seek and replicate
itself.  Code Red of course only can affect unpatched vulnerable IIS
servers. 

Of course, there have been plenty of buffer overflows identified in
Linux based applications, Microsoft-based systems are just a bigger (and
presumably more lucrative) target. Most program development projects
actively check their code for the possibility of buffer-overflows -
hopefully they find the holes before potential attackers do. There is
also work being done on various hardware and software architectures that
limit the ability of unauthorised code to execute on a platform.

 For the average user, provided you limit your internet facing profile
using a firewall configured to only let necessary traffic in , and are
vigilant in patching your systems, you are as safe as you can be. 



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Howard Lowndes
Sent: Thursday, 7 April 2005 7:30 AM
To: Phill
Cc: slug@slug.org.au
Subject: Re: FW: [SLUG] Possible hacker Attempt



Phill wrote:
> I am also curious. How does this attack work? I understand the idea of

> filling up a buffer with junk but then

As Gottfried said, on Linux it doesn't work, but on IIS it causes a
buffer overflow which then allows uncontrolled access for the exploit -
or something like that - I don't pay btoo much attention to Microsoft
type problems.

> 
> Regards,
> Phill
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Gottfried Szing
> Sent: Thursday, 7 April 2005 1:39 AM
> To: slug@slug.org.au
> Subject: Re: [SLUG] Possible hacker Attempt
> 
> hi
> 
> 
>>"GET /default.ida?X...(lots of X's)...X
>>
> 
>
%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801
%u
> 
>>9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a
> 
> HTTP/1.0"
> 
>>404 300 "-" "-"
> 
> 
> isn't that the code red worm? still in the wild?
> 
> 
>>"SEARCH /\x90\x02\xb1\.. ("x02\xb1\" repeats hundreds of times)
>>.\ x02\xb1\x90\...(repeats hundreds of
>>times)...\x90\x90\x90\x90\x90\x90" 414 341 "-" "-"
> 
> 
> AFAIR this is an request that uses an exploit of the IIS and webdav
> component (unchecked buffer).
> 
> but as long as you don't have IIS and windows running, nothing to fear
> about. both attacks works with IIS only and can be ignored on apache.
they
> are just annoying (messing up the logs) but they cannot compromise the
> system.
> 
> cu
> 
> --
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
> 

-- 
Howard.
LANNet Computing Associates - Your Linux people <http://lannet.com.au>
-- 
When you just want a system that works, you choose Linux;
When you want a system that just works, you choose Microsoft.
-- 
Flatter government, not fatter government;
Get rid of the Australian states.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


FW: FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread Phill
Thanks Martin!! Very helpful

Regards,
Phill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Visser, Martin
Sent: Thursday, 7 April 2005 9:19 AM
Cc: slug@slug.org.au
Subject: RE: FW: [SLUG] Possible hacker Attempt

Unfortunately a buffer-overflow is not only a Microsoft problem.

In simple terms, it occurs where an attacker is able to exploit a
programming flaw that allows a program to accept more data then it is
really designed for. Most programs that accept input from the network
(or other input device) will prepare a buffer, some memory space, to
accept that input. If the program is written correctly it should
validate the input or use other some mechnanism to ensure the input does
not exceed the size of the allocated buffer. However, in certain program
architectures, data that is accepted which is more than the buffer can
handle could overwrite existing program data. If this excess data is
craftily designed,  the program can be "tricked" to then execute this
excess data (which is now not just data, but now part of the compromised
programs instructions) and will run with the priveleges of the exploited
program. The excess data is a small chunk of compiled code specifically
designed to run on the target platform - it is usually caused by
inserting a "jump" in the normal code instructions.

In the Code Red example below the attacker is sending a GET request to a
web server. In a vulnerable IIS web server, the URL specified in the
request is much larger than it expected. This data ends up in the web
servers running program space, and is executed by the target system.
The Code Red worm can then do it's job to continue to seek and replicate
itself.  Code Red of course only can affect unpatched vulnerable IIS
servers.

Of course, there have been plenty of buffer overflows identified in
Linux based applications, Microsoft-based systems are just a bigger (and
presumably more lucrative) target. Most program development projects
actively check their code for the possibility of buffer-overflows -
hopefully they find the holes before potential attackers do. There is
also work being done on various hardware and software architectures that
limit the ability of unauthorised code to execute on a platform.

 For the average user, provided you limit your internet facing profile
using a firewall configured to only let necessary traffic in , and are
vigilant in patching your systems, you are as safe as you can be.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Howard Lowndes
Sent: Thursday, 7 April 2005 7:30 AM
To: Phill
Cc: slug@slug.org.au
Subject: Re: FW: [SLUG] Possible hacker Attempt



Phill wrote:
> I am also curious. How does this attack work? I understand the idea of

> filling up a buffer with junk but then

As Gottfried said, on Linux it doesn't work, but on IIS it causes a
buffer overflow which then allows uncontrolled access for the exploit -
or something like that - I don't pay btoo much attention to Microsoft
type problems.

>
> Regards,
> Phill
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Gottfried Szing
> Sent: Thursday, 7 April 2005 1:39 AM
> To: slug@slug.org.au
> Subject: Re: [SLUG] Possible hacker Attempt
>
> hi
>
>
>>"GET /default.ida?X...(lots of X's)...X
>>
>
>
%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801
%u
>
>>9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a
>
> HTTP/1.0"
>
>>404 300 "-" "-"
>
>
> isn't that the code red worm? still in the wild?
>
>
>>"SEARCH /\x90\x02\xb1\.. ("x02\xb1\" repeats hundreds of times)
>>.\ x02\xb1\x90\...(repeats hundreds of
>>times)...\x90\x90\x90\x90\x90\x90" 414 341 "-" "-"
>
>
> AFAIR this is an request that uses an exploit of the IIS and webdav
> component (unchecked buffer).
>
> but as long as you don't have IIS and windows running, nothing to fear
> about. both attacks works with IIS only and can be ignored on apache.
they
> are just annoying (messing up the logs) but they cannot compromise the
> system.
>
> cu
>
> --
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
>

--
Howard.
LANNet Computing Associates - Your Linux people <http://lannet.com.au>
--
When you just want a system that works, you choose Linux;
When you want a system that just works, you choose Microsoft.
--
Flatter government, not fatter government;
Get rid of the Australian states.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


smime.p7s
Description: S/MIME cryptographic signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

RE: FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread Visser, Martin
BTW you can have finding the known vulnerabilities in your favourite
software from various sites - eg
http://secunia.com/search/?search=apache+buffer+overflow 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Phill
Sent: Thursday, 7 April 2005 9:32 AM
To: slug@slug.org.au
Subject: FW: FW: [SLUG] Possible hacker Attempt

Thanks Martin!! Very helpful

Regards,
Phill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Visser, Martin
Sent: Thursday, 7 April 2005 9:19 AM
Cc: slug@slug.org.au
Subject: RE: FW: [SLUG] Possible hacker Attempt

Unfortunately a buffer-overflow is not only a Microsoft problem.

In simple terms, it occurs where an attacker is able to exploit a
programming flaw that allows a program to accept more data then it is
really designed for. Most programs that accept input from the network
(or other input device) will prepare a buffer, some memory space, to
accept that input. If the program is written correctly it should
validate the input or use other some mechnanism to ensure the input does
not exceed the size of the allocated buffer. However, in certain program
architectures, data that is accepted which is more than the buffer can
handle could overwrite existing program data. If this excess data is
craftily designed,  the program can be "tricked" to then execute this
excess data (which is now not just data, but now part of the compromised
programs instructions) and will run with the priveleges of the exploited
program. The excess data is a small chunk of compiled code specifically
designed to run on the target platform - it is usually caused by
inserting a "jump" in the normal code instructions.

In the Code Red example below the attacker is sending a GET request to a
web server. In a vulnerable IIS web server, the URL specified in the
request is much larger than it expected. This data ends up in the web
servers running program space, and is executed by the target system.
The Code Red worm can then do it's job to continue to seek and replicate
itself.  Code Red of course only can affect unpatched vulnerable IIS
servers.

Of course, there have been plenty of buffer overflows identified in
Linux based applications, Microsoft-based systems are just a bigger (and
presumably more lucrative) target. Most program development projects
actively check their code for the possibility of buffer-overflows -
hopefully they find the holes before potential attackers do. There is
also work being done on various hardware and software architectures that
limit the ability of unauthorised code to execute on a platform.

 For the average user, provided you limit your internet facing profile
using a firewall configured to only let necessary traffic in , and are
vigilant in patching your systems, you are as safe as you can be.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Howard Lowndes
Sent: Thursday, 7 April 2005 7:30 AM
To: Phill
Cc: slug@slug.org.au
Subject: Re: FW: [SLUG] Possible hacker Attempt



Phill wrote:
> I am also curious. How does this attack work? I understand the idea of

> filling up a buffer with junk but then

As Gottfried said, on Linux it doesn't work, but on IIS it causes a
buffer overflow which then allows uncontrolled access for the exploit -
or something like that - I don't pay btoo much attention to Microsoft
type problems.

>
> Regards,
> Phill
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Gottfried Szing
> Sent: Thursday, 7 April 2005 1:39 AM
> To: slug@slug.org.au
> Subject: Re: [SLUG] Possible hacker Attempt
>
> hi
>
>
>>"GET /default.ida?X...(lots of X's)...X
>>
>
>
%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801
%u
>
>>9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a
>
> HTTP/1.0"
>
>>404 300 "-" "-"
>
>
> isn't that the code red worm? still in the wild?
>
>
>>"SEARCH /\x90\x02\xb1\.. ("x02\xb1\" repeats hundreds of times) 
>>.\ x02\xb1\x90\...(repeats hundreds of 
>>times)...\x90\x90\x90\x90\x90\x90" 414 341 "-" "-"
>
>
> AFAIR this is an request that uses an exploit of the IIS and webdav 
> component (unchecked buffer).
>
> but as long as you don't have IIS and windows running, nothing to fear

> about. both attacks works with IIS only and can be ignored on apache.
they
> are just annoying (messing up the logs) but they cannot compromise the

> system.
>
> cu
>
> --
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ 
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
>

--
Howard.
LANNet Computing Associates - 

Re: FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread Howard Lowndes
My bad.  Of course Linux apps can be just as badly written as M$ apps 
and can have buffer overflows.

What I should have said is that this attempt at a buffer over flow does 
not affect Apache.

Phill wrote:
OK. I did a bit of reading on the subject. Linux can be vulnerable to
buffer overrun attacks can't it? If not, why not?
Regards,
Phill
-Original Message-
From: Howard Lowndes [mailto:[EMAIL PROTECTED]
Sent: Thursday, 7 April 2005 7:30 AM
To: Phill
Cc: slug@slug.org.au
Subject: Re: FW: [SLUG] Possible hacker Attempt

Phill wrote:
I am also curious. How does this attack work? I understand the idea of
filling up a buffer with junk but then

As Gottfried said, on Linux it doesn't work, but on IIS it causes a
buffer overflow which then allows uncontrolled access for the exploit -
or something like that - I don't pay btoo much attention to Microsoft
type problems.

Regards,
Phill
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of Gottfried Szing
Sent: Thursday, 7 April 2005 1:39 AM
To: slug@slug.org.au
Subject: Re: [SLUG] Possible hacker Attempt
hi

"GET /default.ida?X...(lots of X's)...X

%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u
9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a
HTTP/1.0"

404 300 "-" "-"

isn't that the code red worm? still in the wild?

"SEARCH /\x90\x02\xb1\.. ("x02\xb1\" repeats hundreds of times)
.\ x02\xb1\x90\...(repeats hundreds of
times)...\x90\x90\x90\x90\x90\x90" 414 341 "-" "-"

AFAIR this is an request that uses an exploit of the IIS and webdav
component (unchecked buffer).
but as long as you don't have IIS and windows running, nothing to fear
about. both attacks works with IIS only and can be ignored on apache.
they
are just annoying (messing up the logs) but they cannot compromise the
system.
cu
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

--
Howard.
LANNet Computing Associates - Your Linux people <http://lannet.com.au>
--
When you just want a system that works, you choose Linux;
When you want a system that just works, you choose Microsoft.
--
Flatter government, not fatter government;
Get rid of the Australian states.
--
Howard.
LANNet Computing Associates - Your Linux people <http://lannet.com.au>
--
When you just want a system that works, you choose Linux;
When you want a system that just works, you choose Microsoft.
--
Flatter government, not fatter government;
Get rid of the Australian states.
begin:vcard
fn:Howard Lowndes
n:Lowndes;Howard
org:LANNet Computing Associates
adr:;;PO Box 1174;Lavington;NSW;2641;Australia
email;internet:howard [AT] lowndes [DOT] name
tel;work:02 6040 0222
tel;fax:02 6040 0222
tel;cell:0419 464 430
note:I am heartily sick and tired of telemarketers, therefore I do not answer phone calls which do not present Caller Line Identification, they get flicked to voicemail.  I apologise if this inconveniences you, and I respect your right to not identify yourself, but I also ask that you respect my right to not answer your call if you choose not to identify yourself.  Try dialing 1832 (#32# from mobiles) before the number, to present Caller Line Identification.
x-mozilla-html:FALSE
url:http://www.lannet.com.au
version:2.1
end:vcard

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread telford
On Thu, Apr 07, 2005 at 09:48:48AM +1000, Howard Lowndes wrote:
> My bad.  Of course Linux apps can be just as badly written as M$ apps 
> and can have buffer overflows.
> 
> What I should have said is that this attempt at a buffer over flow does 
> not affect Apache.


Whilst Linux apps can be badly written, there are a few reasons why
Microsoft apps tend to be worse. Consider that most of the people who
program for Linux have also tried working with Microsoft products and
they chose Linux because they wanted to do things the right way. This
has a filtering effect that pulls the strongest programmers away from
MS and toward either Linux or one of the *BSD variations. People who
care about money first and producing a good product second will tend
to go to the Microsoft camp, people who think that a good product
should be first priority and then look at money as a secondary
consideration usually gravitate in a free-software direction. Its
a difference of emphasis rather than a completely different approach
but it does make a difference.

Then there are the Microsoft customers who have not (until recently)
been willing to get nasty about software quality. With market forces
at work, if there is no demand for high security, high quality software
there will also be no supply. When Microsoft had a total monopoly
they just didn't have to care one way or the other... now that their
monopoly is weakening and some customers are getting aggressive they
are forced to care so they are making more of an effort.

As a practical example to all those C programmers out there, this is
the common idiom (since early K&R days):

int myfunc( char *stuff )
{
char buf[ 100 ];

sprintf( buf, "My stuff is %s", stuff );
/* do something with buf here */
}

Of course this is exactly what will sting you if you can't be sure
what "stuff" might contain (in technical terms we say that "stuff"
is tainted so we can't trust it). The trick is that the C compiler
puts the "buf" variable on the stack and also puts the function
return address on the SAME stack AFTER buf when it calls sprintf().
Using the same stack for variables and code pointers is a good
optimisation for speed but it is bad for security because when
the "stuff" is too big it wipes over the return address. With some
care, it can replace the return address with a pointer into itself
which sets to program running onto a completely new chunk of code.

Now redhat (and others) have a few tricks to make that more difficult,
the first is to limit the executable sections of memory and make
it illegal for executable code to exist inside stack buffers. It is
interesting that Microsoft were talking about how important this
feature is and how they would have it real-soon-now at the same time
that Redhat were shipping with it enabled. The second is using a
randomised offset for various memory chunks in the program to make
it much more difficult to figure out what return address to load
into "stuff" to make it do what you want -- then the hacked program
merely crashes rather than opening a back door. Redhat also ships
with that feature.

The easiest source-code fix is to use the snprintf() function so
that the buffer size is known to the formatter like so:

int myfunc( char *stuff )
{
char buf[ 100 ];

snprintf( buf, 100, "My stuff is %s", stuff );
/* do something with buf here */
}

But the snprintf() call is not POSIX, it is from BSD (and now adopted
by Linux) and last I looked Microsoft C did NOT provide that function.
Of course there are lots of other ways to protect yourself but the
Microsoft programmers are forced to do it the hard way.

Worse... when porting code from Linux and BSD onto Microsoft, the people
doing the port find there is no snprintf() so they knock up a quick
compatibility library that just ignores the buffer length and calls
sprintf() resulting in a nasty vulnerability but only in the Microsoft
version. Note that early Linux implementations (libc 4) had the same
hasty hack but it got fixed and I doubt that there are too many of
those old Linux boxes running on the Internet these days.


So yes, anyone can write bad code but in practical terms Microsoft
still has a bit of catching up to do.


- Tel  ( http://bespoke.homlinux.net/ )
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread Howard Lowndes
Tks Tel, that is a brilliant explanation for someone like me who doesn't 
know C from Z :)

[EMAIL PROTECTED] wrote:
On Thu, Apr 07, 2005 at 09:48:48AM +1000, Howard Lowndes wrote:
My bad.  Of course Linux apps can be just as badly written as M$ apps 
and can have buffer overflows.

What I should have said is that this attempt at a buffer over flow does 
not affect Apache.

Whilst Linux apps can be badly written, there are a few reasons why
Microsoft apps tend to be worse. Consider that most of the people who
program for Linux have also tried working with Microsoft products and
they chose Linux because they wanted to do things the right way. This
has a filtering effect that pulls the strongest programmers away from
MS and toward either Linux or one of the *BSD variations. People who
care about money first and producing a good product second will tend
to go to the Microsoft camp, people who think that a good product
should be first priority and then look at money as a secondary
consideration usually gravitate in a free-software direction. Its
a difference of emphasis rather than a completely different approach
but it does make a difference.
Then there are the Microsoft customers who have not (until recently)
been willing to get nasty about software quality. With market forces
at work, if there is no demand for high security, high quality software
there will also be no supply. When Microsoft had a total monopoly
they just didn't have to care one way or the other... now that their
monopoly is weakening and some customers are getting aggressive they
are forced to care so they are making more of an effort.
As a practical example to all those C programmers out there, this is
the common idiom (since early K&R days):
int myfunc( char *stuff )
{
char buf[ 100 ];

sprintf( buf, "My stuff is %s", stuff );
/* do something with buf here */
}
Of course this is exactly what will sting you if you can't be sure
what "stuff" might contain (in technical terms we say that "stuff"
is tainted so we can't trust it). The trick is that the C compiler
puts the "buf" variable on the stack and also puts the function
return address on the SAME stack AFTER buf when it calls sprintf().
Using the same stack for variables and code pointers is a good
optimisation for speed but it is bad for security because when
the "stuff" is too big it wipes over the return address. With some
care, it can replace the return address with a pointer into itself
which sets to program running onto a completely new chunk of code.
Now redhat (and others) have a few tricks to make that more difficult,
the first is to limit the executable sections of memory and make
it illegal for executable code to exist inside stack buffers. It is
interesting that Microsoft were talking about how important this
feature is and how they would have it real-soon-now at the same time
that Redhat were shipping with it enabled. The second is using a
randomised offset for various memory chunks in the program to make
it much more difficult to figure out what return address to load
into "stuff" to make it do what you want -- then the hacked program
merely crashes rather than opening a back door. Redhat also ships
with that feature.
The easiest source-code fix is to use the snprintf() function so
that the buffer size is known to the formatter like so:
int myfunc( char *stuff )
{
char buf[ 100 ];

snprintf( buf, 100, "My stuff is %s", stuff );
/* do something with buf here */
}
But the snprintf() call is not POSIX, it is from BSD (and now adopted
by Linux) and last I looked Microsoft C did NOT provide that function.
Of course there are lots of other ways to protect yourself but the
Microsoft programmers are forced to do it the hard way.
Worse... when porting code from Linux and BSD onto Microsoft, the people
doing the port find there is no snprintf() so they knock up a quick
compatibility library that just ignores the buffer length and calls
sprintf() resulting in a nasty vulnerability but only in the Microsoft
version. Note that early Linux implementations (libc 4) had the same
hasty hack but it got fixed and I doubt that there are too many of
those old Linux boxes running on the Internet these days.
So yes, anyone can write bad code but in practical terms Microsoft
still has a bit of catching up to do.
	- Tel  ( http://bespoke.homlinux.net/ )
--
Howard.
LANNet Computing Associates - Your Linux people 
--
When you just want a system that works, you choose Linux;
When you want a system that just works, you choose Microsoft.
--
Flatter government, not fatter government;
Get rid of the Australian states.
begin:vcard
fn:Howard Lowndes
n:Lowndes;Howard
org:LANNet Computing Associates
adr:;;PO Box 1174;Lavington;NSW;2641;Australia
email;internet:howard [AT] lowndes [DOT] name
tel;work:02 6040 0222
tel;fax:02 6040 0222
tel;cell:0419 464 430
note:I am heartily sick and tired of telemarketers, therefore I do not 

Re: FW: [SLUG] Possible hacker Attempt

2005-04-06 Thread Grant Parnell - slug
On Thu, 7 Apr 2005, Phill wrote:

> I am also curious. How does this attack work? I understand the idea of
> filling up a buffer with junk but then

Basically a snapshot of a bit of memory might look like this after 
processing the URL http://localhost/cgi-bin/?HELLO-WORLD

byte:   content:
:   H E L L O - W O R L D 
0016:   

If the bit after the '?' character in the GET URL is inserted at byte 00 
by apache for which it has only allocated 16 bytes then by adding more 
bytes you overwrite some code which at some point probably gets run. Key 
difference, under Linux it's only going to run as the user the original 
program was running as (eg www or apache). 

eg 
http://localhost/cgi-bin/?

It sometimes doesen't matter precisely where the buffer finishes, there's 
a reasonable chance that one of the  bits actually get run (no 
operation, skip to next byte for instruction) and eventually the 
jump_to_code which goes back to the part of the buffer where the payload 
of the exploit is.

These sort of buffer overflow exploits are not only very CPU specific but
often operating system specific as it's making great assumptions about
things like valid CPU op-codes and library calls.

These bugs are often introduced by the use of the C function fgets() and
similar which receives a sting from an input stream and puts it into a 
buffer without regard to length of the buffer. It's so frequent that gcc 
warns you about it's use now. Typically you specify a maximum number of 
characters to accept which presumably is less than or equal to the size of 
the buffer you allocated.

-- 
-- 
Grant Parnell - SLUG President
EverythingLinux services - the consultant's backup & tech support.
Web: http://www.elx.com.au/support.php
We're also busybits.com.au and linuxhelp.com.au and everythinglinux.com.au.
Phone 02 8756 3522 to book service or discuss your needs 
or email us at paidsupport at elx.com.au

ELX or its employees participate in the following:-
OSIA (Open Source Industry Australia) - http://www.osia.net.au
AUUG (Australian Unix Users Group) - http://www.auug.org.au
SLUG (Sydney Linux Users Group) - http://www.slug.org.au
LA (Linux Australia) - http://www.linux.org.au

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: FW: [SLUG] Possible hacker Attempt

2005-04-07 Thread Gottfried Szing

Phill wrote:
What is "AFAIR"
AFAIK this means "As Far As I Remember" ;)
cu, gottfried
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: FW: [SLUG] Possible hacker Attempt

2005-04-07 Thread Ken Foskey
On Thu, 2005-04-07 at 09:22 +1000, Phill wrote:
> OK. I did a bit of reading on the subject. Linux can be vulnerable to
> buffer overrun attacks can't it? If not, why not?

Absolutely.  Everything can be susceptible to these attacks if they are
written in a language that allows it, typically C.

There are tools that instrument executable to "prevent" such attacks but
there is a performance cost and they are often breakable.  There is an
exploit that works with the buffer overrun detection of windows already.

If you have the most secure kernel in history and you run software that
is broken then you may be exposed, eg latest kernel and old version of
apache.  Security and hacker prevention is not about solving one simple
problem, it is a total package.

-- 
Ken Foskey
OpenOffice.org developer


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html