Re: [Full-disclosure] Anti-Virus vendors prove less-effective

James Matthews wrote: > How can these people put out a good product against scripts where you can > change anything and it will still work! Haven't you heard? The AV industry cracked the Halting Problem so we should expect them to do this! Regards, Nick FitzGerald _

Re: [Full-disclosure] Anti-Virus vendors prove less-effective

How can these people put out a good product against scripts where you can change anything and it will still work! On 4/24/07, David Kierznowski <[EMAIL PROTECTED]> wrote: Web Backdoor Compilation along with Dancho Danchev AV research has proven how less-effective many of these products are whe

Re: [Full-disclosure] Apache/PHP REQUEST_METHOD XSS Vulnerability

This is a case of poor-programming, on the script coder's part, it is not so much a vunerability. That variable only contains what it is sent by apache. it doesn't parse it. nor is it supposed to. If you want to ensure there is no XSS going on, parse the variable, escape characters, etc as it IS

[Full-disclosure] Anti-Virus vendors prove less-effective

Web Backdoor Compilation along with Dancho Danchev AV research has proven how less-effective many of these products are when detecting web malware. The results are certainly not a shocker but definately an eye opener. WBC has certainly demonstrated what all security researchers already know, thi

Re: [Full-disclosure] Apache/PHP REQUEST_METHOD XSS Vulnerability

If you use htmlentitles it is still exploitable. The problem is that Apache accepts chars wich it shouldn't. Regards Michal. On 4/24/07, Kradorex Xeron <[EMAIL PROTECTED]> wrote: > This isn't only a problem with that specific variable, it is also a problem > with any user-defined variable, i.e. >

Re: [Full-disclosure] OpenSSH - System Account Enumeration if S/Key is used

On Tue, 24 Apr 2007 11:10:27 +0200 Stanislaw Klekot <[EMAIL PROTECTED]> wrote: > On Sat, Apr 21, 2007 at 02:27:17AM +0200, rembrandt wrote: > > As you can see clearly OpenSSH discloses the existence of system accounts. > > A possible solution for this problem would be to print a fake S/Key-Request

[Full-disclosure] ASA-2007-010: Two stack buffer overflows in SIP channel's T.38 SDP parsing code

>Asterisk Project Security Advisory - ASA-2007-010 > >++ >| Product | Asterisk | >|+--

[Full-disclosure] ASA-2007-012: Remote Crash Vulnerability in Manager Interface

>Asterisk Project Security Advisory - ASA-2007-012 > >++ >| Product | Asterisk | >|-+-

[Full-disclosure] ASA-2007-011: Multiple problems in SIP channel parser handling response codes

>Asterisk Project Security Advisory - ASA-2007-011 > >++ >| Product | Asterisk | >|+--

[Full-disclosure] ZDI-07-022: CA BrightStor ArcServe Media Server Multiple Buffer Overflow Vulnerabilities

ZDI-07-022: CA BrightStor ArcServe Media Server Multiple Buffer Overflow Vulnerabilities http://www.zerodayinitiative.com/advisories/ZDI-07-022.html April 24, 2007 -- CVE ID: CVE-2007-2139 -- Affected Vendor: Computer Associates -- Affected Products: BrightStor ARCserve Backup r11.5

[Full-disclosure] [SECURITY] [DSA 1280-1] New aircrack-ng packages fix arbitrary code execution

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1280-1[EMAIL PROTECTED] http://www.debian.org/security/ Moritz Muehlenhoff April 24th, 2007

[Full-disclosure] Security Advisory: CA CleverPath SQL Injection

Background == The CA Clever Path Portal is a customizable portal for aggregation and integration of data and applications. It is integrated into multiple CA products including various Unicenter components. The CA CleverPath utilizes a back end Database for storing data and allows usage of e

[Full-disclosure] [ GLSA 200704-21 ] ClamAV: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200704-21 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - -

Re: [Full-disclosure] OpenSSH - System Account Enumeration if S/Key is used

On 4/24/07, Stanislaw Klekot <[EMAIL PROTECTED]> wrote: > Look closer to challenge message. There's salt and key number included. > Consider now three logins: first isn't valid account on the target > system, second is valid but without OTP set, and third with OTP set. > First two are indistinguish

[Full-disclosure] rPSA-2007-0081-1 postgresql postgresql-server

rPath Security Advisory: 2007-0081-1 Published: 2007-04-24 Products: rPath Linux 1 Rating: Major Exposure Level Classification: Local Deterministic Privilege Escalation Updated Versions: postgresql=/[EMAIL PROTECTED]:devel//1/8.1.9-0.1-1 postgresql-server=/[EMAIL PROTECTED]:devel//1/8.1

Re: [Full-disclosure] Apache/PHP REQUEST_METHOD XSS Vulnerability

This isn't only a problem with that specific variable, it is also a problem with any user-defined variable, i.e. can be XSS'd with script.php?page=blah However: is much harder to exploit to inject malicious code. I beleive the following: If your program/script accepts any user input, never

[Full-disclosure] Linksys SPA941 remote DOS with \377 character

MADYNES Security Advisory http://madynes.loria.fr Title: Linksys SPA941 remote DOS with \377 character Discovery Date: 01/02/2007 Vendor notification: 4/04/2007 and 17/04/2007 Release Date: 24/04/2007 Severity: Moderate - Denial of Servi

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

KJKHyperion wrote: > Michal Majchrowicz wrote: >> In this case I agree this is a solution. If Apache wouldn't accept any >> 'separators' then XSS (and other stuff) wouldn't be possible at all. Is >> there anywhere described which chars can be used in protocol "field"? > There is no "flaw". I agr

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

Michal Majchrowicz wrote: > In this case I agree this is a solution. If Apache wouldn't accept any > 'separators' then XSS (and other stuff) wouldn't be possible at all. Is there > anywhere described which chars can be used in protocol "field"? There is no "flaw". You clearly have never written a

Re: [Full-disclosure] [VulnWatch] Apache/PHP REQUEST_METHOD XSS Vulnerability

Hi. I am talking about standard apache installation. And there is something like this only: AllowOverride FileInfo AuthConfig Limit -Indexes Options MultiViews -Indexes SymLinksIfOwnerMatch IncludesNoExec Order allow,deny Allow from all

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

That would severely cut most extensibility and require further implementations to be hardcoded, thus limiting apache's modular nature. The original RFC would be insufficient for it's list as there are modules such as webdav (as in the previous example) that add to that list of methods Apache is

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

That would severely cut most extensibility and require further implementations to be hardcoded, thus limiting apache's modular nature. The original RFC would be insufficient for it's list as there are modules such as webdav (as in the previous example) that add to that list of methods Apache is

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

That would severely cut most extensibility and require further implementations to be hardcoded, thus limiting apache's modular nature. The original RFC would be insufficient for it's list as there are modules such as webdav (as in the previous example) that add to that list of methods Apache is

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

In this case I agree this is a solution. If Apache wouldn't accept any 'separators' then XSS (and other stuff) wouldn't be possible at all. Is there anywhere described which chars can be used in protocol "field"? Regards Michal. On 4/24/07, Richard Moore <[EMAIL PROTECTED]> wrote: > Michal Majchro

Re: [Full-disclosure] OpenSSH - System Account Enumeration if S/Key is used

On Sat, Apr 21, 2007 at 02:27:17AM +0200, rembrandt wrote: > As you can see clearly OpenSSH discloses the existence of system accounts. > A possible solution for this problem would be to print a fake S/Key-Request > even for non existing users as well as it`s done with the > Passwordauthentication

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

Michal Majchrowicz wrote: > Okay so let's assume that there cany "anything" as the request. But > there has to be something that handles this request? If there is no > "handler" for request "" Apache should return error page. And > what about protocol version? You didn't answer this question. > Reg

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

Okay so let's assume that there cany "anything" as the request. But there has to be something that handles this request? If there is no "handler" for request "" Apache should return error page. And what about protocol version? You didn't answer this question. Regards Michal. On 4/24/07, Richard Mo

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

On 4/24/07, Michal Majchrowicz <[EMAIL PROTECTED]> wrote: > Hi. > I think now we can classify this as flaw in Apache. It accepts > requests that simply make no sense. Take a look at this example: > alert(document.cookie); /test.php > alert(document.cookie); > In some circumstances it may cause XSS

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

Hi. I think that server should have a list of valid requests. In fact Apache warns you sometimes that valid requests are: "GET/POST/TRACE/OPTIONS". The solution that it just accepts everything as request and protocol makes no sense. What kind of protocol is ""? Regards Michal. On 4/24/07, Richard

Re: [Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

Michal Majchrowicz wrote: > Hi. > I think now we can classify this as flaw in Apache. It accepts > requests that simply make no sense. Take a look at this example: > alert(document.cookie); /test.php > alert(document.cookie); > In some circumstances it may cause XSS vulnerability: > echo $

[Full-disclosure] Apache Illegal Request Handling Possible XSS Vulnerability

Hi. I think now we can classify this as flaw in Apache. It accepts requests that simply make no sense. Take a look at this example: alert(document.cookie); /test.php alert(document.cookie); In some circumstances it may cause XSS vulnerability: I am now investigating other possible attacks. Regards