[Full-disclosure] Re: Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through forged magic byte

[x]

Andrey Bayora said:
+ > If your altered virus sample
+ > still executes correctly, you have simply created a new 
+ > virus variant.
+
+ Not exactly, please look at this virustotal.com log
+ http://www.securityelf.org/updmagic.html
+
+ The altered (120 bytes prepended) TXT_* variant is STILL 
+ detected by your product (CA), but when I change the first 
+ byte from "Z" to "M" - your product fails (MZ_* variant). 
+ I believe, that if I PREPEND 120 bytes to known virus and 
+ the virus is still detected with the SAME signature - 
+ then I DID NOT create a new variant. Now one more example: 
+ try to change the first byte "Z" in the TXT_* variant to 
+ any value, but not to "M" - this virus will be detected, 
+ but when you change to "M", thus creating the .EXE magic 
+ byte - the variant is not detected !!!  My conclusion: 
+ the antivirus “thought” that the file is the executable 
+ type instead of determining the file type by the 
+ extension.
+ 
+ That is my point, if you still think that your product is 
+ OK - do not do anything.

Thierry Zoller said:
+ WJK> You are effectively altering existing viruses to the 
+ WJK> point that AV scanners do not detect them.
+ 
+ No, he is changing a few bytes only.
+ 
+ WJK> If your altered virus sample still executes 
+ WJK> correctly, you have simply created a new virus 
+ WJK> variant.
+ 
+ No, there is no variant, the virus executes EXACTLY as 
+ before. A variant acts differenlty then a precedent 
+ version, else it would be no variant. To your AV engine it 
+ is a variant, yes, but only because it is flawed.

Why are you guys having such a difficult time comprehending 
this?  Read both the general and AV-specific definitions of 
the word "variant".

http://dictionary.reference.com/search?q=variant
http://www.symantec.com/avcenter/glossary/index.html#v
http://us.mcafee.com/VirusInfo/VIL/glossary_app.asp#v

If you take an existing virus and modify it, you have 
created a variant.

The AV vendors aren't going to patch their products if they 
don't detect your PoC; they're just going to write a new 
signature or modify an existing signature to detect your 
new variants.  The fact that it can and will be fixed by 
AV signatures instead of product patches should help you 
figure out if this is a product vulnerability issue or just
a "new virus variant" issue.

BTW, Andrey, did you bother to use the "deep scan", 
"heuristic mode", "reviewer mode", etc to see if any
of those AV scanners picked up your new variants?  I bet
you didn't.

Thierry Zoller said:
+ WJK> Consequently, the issue that you describe is *not* a
+ WJK> vulnerability issue, but rather just an example of a 
+ WJK> new variant that has not yet been added to an AV 
+ WJK> vendor's database of "known viruses".
+ 
+ Thank you James, this _to my knowledge_ (perhaps the guy 
+ from vmyths knows better) is the first time the complete 
+ failure of todays AV solutions is shown naked publicaly 
+ directly by a representant of an AV company. This 
+ statement coming from a AV vendor is simply exposing what 
+ is known in the sec. community since many years.

To say that an AV scanner is a "complete failure" because it 
fails to detect a variant you just created is inane.  Each 
of the top 10 AV scanners detects well over 95% of all known 
viruses.  The AV scanners aren't perfect, but they 
definitely make a BIG BIG difference wrt malware risk 
mitigation.

ftp://agn-www.informatik.uni-hamburg.de/pub/texts/tests/pc-av/2003-04/0xecsum.txt

Thierry Zoller said:
+ The solution was to make the engines a bit "smarter", i.e 
+ analyse the header to determine the type and then ONLY 
+ apply the signatures/heuristics which apply to the type of 
+ the file (i am not speaking about the extension of the 
+ file here) thus speeding up the process. Changing the 
+ header just makes the smart engines look...well...  a bit 
+ dumb in my regards.

There are two types of people in the world:  those who 
complain about problems, and those who find solutions to
problems.  Where's your superior AV scanner?

--
x @ bos


___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Multiple vulnerabilities within RockLiffe MailSite Express WebMail

[Paul Craig]

= Multiple vulnerabilities within RockLiffe MailSite Express WebMail
=
= Also available online at 
=
http://www.security-assessment.com/Advisories/Rockliffe_Express_Webmail_Vuln
erabilities.pdf
=
= Vendor Website: 
= http://www.rockliffe.com
=
= Affected Version:
= All versions of RockLiffe MailSite Express WebMail prior v6.1.22
= 
=
= Public disclosure on October 28th, 2005


== Overview ==

During an audit of a client, Security-Assessment.com discovered multiple 
critical vulnerabilities within the RockLiffe MailSite Express WebMail 
software. 

The vulnerabilities include the retrieval of arbitrary files from the
web server, and bypassing attachment validation routines allowing for  
remote code execution.

== Exploitation ==

Exploit 1: Cross Site Scripting Vulnerabilities


Recipients who save their login information locally are vulnerable to 
account theft when viewing HTML encoded messages with embedded JavaScript.

When the option to save login information is selected the users password
is stored as plaintext within the cookie.

Crafting an email with scripting in the body will cause the execution of
the scripting in the context of the site, allowing for the theft of the
stored credentials.

A basic test for this is to include the following in the body of a message;
 alert(document.cookie) 

Exploit 2: Multiple Script Attachment Validation Flaws


The WebMail software attempts to verify the validity of an attachment within
a received message. It automatically modifies the extension of any files
ending in .asp, by changing them to .asp.txt. This is an attempt to avoid
remote code execution through an attached file.

However, these validity checks can be defeated and script files saved to
the server.

By default, only files ending in .asp are identified and rejected as script
files.  If a malicious user were to attach an .asa file instead, Web Mail
would accept the script attachment, saving the file locally with the
.asa extension.

When the .asa file is requested the script contents are executed in the same
manner as a .asp file. This flaw could also be affected by other extensions
such as .htr and .aspx.

A similar flaw exists when an attachment is sent with the filename
unknown.unk.

In this instance the message subject is used as the file name, and .asa
script files can be saved locally.

Exploit 3: Retrieve Arbitrary System Files via Web Mail


The location of file attachments for a mail message currently been composed,
are stored as a physical file path included in the HTML as a hidden field.

An example of this is shown below;

http://www.rockliffe.com/userroom/download.asp
 
== Credit ==

Discovered and advised to RockLiffe software July, 2005 by Paul Craig of
Security-Assessment.com

== About Security-Assessment.com ==

Security-Assessment.com is a leader in intrusion testing and security
code review, and leads the world with SA-ISO, online ISO17799 compliance
management solution. Security-Assessment.com is committed to security
research and development, and its team have previously identified a
number of vulnerabilities in public and private software vendors products.

 

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] RFID docs & tools ?

[KF (lists)]

http://rfidanalysis.org/
-KF


Mark Sec wrote:


Alo folks,


Well , does anyone know links to buy "lectors" RFID ?

I would like to do a "PoCs" on Hacking RFID , also i need tools,
pappers, PoCs & links related with this.

thanks :-)


- Mark
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/



 



___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] RFID docs & tools ?

[Mark Sec]

Alo folks,


Well , does anyone know links to buy "lectors" RFID ?

I would like to do a "PoCs" on Hacking RFID , also i need tools,
pappers, PoCs & links related with this.

thanks :-)


- Mark
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] RE: Full-Disclosure Digest, Vol 8, Issue 48

[Stejerean, Cosmin]

>> If your altered virus sample
?> still executes correctly, you have simply created a new virus
?> variant.
>
>Not exactly, please look at this virustotal.com log
>http://www.securityelf.org/updmagic.html
>
>The altered (120 bytes prepended) TXT_* variant is STILL detected by your
>product (CA), but when I change the first byte from "Z" to "M" - your
>product
>fails (MZ_* variant).

The virus scanner determined the type of the file by the header and it
failed. That's bad news. I am wondering however, when I execute that file,
how does the OS process the file? I guess my question is, if I have a
modified version of a virus, with whatever header, if I try to execute that
file, will the virus code get executed?


Cosmin Stejerean



smime.p7s
Description: S/MIME cryptographic signature
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Question about ethics when discovering a securityfault in system

[Morning Wood]

Work with the company, coridinate an advisory release when they have the
update avail.
Chances are you will recieve some form of a credit, thanking you for finding
the flaw, and brining it to the mfg's attention.

cheers
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Question about ethics when discovering a security fault in system

[Michael Holstein]

My question is what is good ethics for me to continue with this? Sense I 
discovered it by mistake, and everyone can do the same thing and 
everyone can reproduce it. And it is a perimeter security device 
providing remote access from a large manufacturer. And might be a known 
problem by others than the manufacturer, how ever the product has only 
bean on the market for about 2 months.


You write up your advisory, like many that you see here, without 
revealing the details of the exploit.


What I want a resolution so the device we bought to provide us with 
remote access and security shall work securely and that the company 
shall inform other owner of there products about the problem so they 
wont have the same security breach.


Standard practice is to give the vendor a reasonable amount of time to 
respond. (exact value of that depends on the person .. I'd say ~30 days 
is average .. but some will wait until some number of days AFTER a patch 
is released) -- then you release a modified version of your advisory 
with the exploit details.


Sure .. others might discover it "by accident" .. but security 
researchers that do that aren't the folks that'd write worms or go 
hacking about. It's the scriptkiddies that read PoC code on FD and 
elsewhere that do. Write the advisory (claim your credit of discovery), 
leave out the gory details, and wait for the vendor (reasonably).


Sometimes you've got to nail them with PoC code to get the fire lit .. 
but usually they don't like getting embarassed that way.


Cheers,

Michael Holstein CISSP GCIA
Cleveland State University
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Hasbani-WindWeb/2.0 Remote DoS [ with exploit ]

[Expanders]

[i] 
Title:  
Hasbani-WindWeb/2.0 - HTTP GET  Remote DoS[i] Discovered 
by:  Expanders[i] Exploit 
by: Expanders
 
[ What is Hasbani-WindWeb/2.0 ]
 
Hasbani server is a httpd created for menaging 
ethernet routers and adsl modems.
 
[ Why HTTPD crash? ]
 
Causes of DoS are not perfecly known by me 'cos i 
can't debug a chip-integrated http daemon.Btw seems that Hasbani enter a 
loop in a GET /..:..:..etc. condition, causes that when an attacker reguest a 
long crafted stringserver enter an endless loop with conseguenly crash of 
the httpd.
 
NOTE: This exploit DON'T drop down victim's adsl 
connection!
 
[ Exploit ]
 
Attacked or
 
http://download.x0n3-h4ck.org/XH-Hasbani-HTTPD-DoS.c
 
[ Timeline ]
 
This vulnerability was not comunicated because i 
did'n find Hasbani's vendor.
 
[ Links ]
 
www.x0n3-h4ck.org


XH-Hasbani-HTTPD-DoS.c
Description: Binary data
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] MDKSA-2005:201 - Updated sudo packages fix vulnerability

[Mandriva Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___
 
 Mandriva Linux Security Advisory MDKSA-2005:201
 http://www.mandriva.com/security/
 ___
 
 Package : sudo
 Date: October 27, 2005
 Affected: 10.1,  10.2,  2006.0,  Corporate 2.1,  Corporate 3.0,
   Multi Network Firewall 2.0
 ___
 
 Problem Description:
 
 Tavis Ormandy discovered that sudo does not perform sufficient
 environment cleaning; in particular the SHELLOPTS and PS4 variables are
 still passed to the program running as an alternate user which can
 result in the execution of arbitrary commands as the alternate user
 when a bash script is executed.
 
 The updated packages have been patched to correct this problem.
 ___

 References:
 
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2959
 ___
 
 Updated Packages:
 
 Corporate Server 2.1:
 f7a973c064788876a3927e23698165e7  
corporate/2.1/RPMS/sudo-1.6.6-2.3.C21mdk.i586.rpm
 9d41a3e0d779287d5d6defe3effeadb6  
corporate/2.1/SRPMS/sudo-1.6.6-2.3.C21mdk.src.rpm

 Corporate Server 2.1/X86_64:
 11dee7cd0ef65739fbcb74eb4435abb7  
x86_64/corporate/2.1/RPMS/sudo-1.6.6-2.3.C21mdk.x86_64.rpm
 9d41a3e0d779287d5d6defe3effeadb6  
x86_64/corporate/2.1/SRPMS/sudo-1.6.6-2.3.C21mdk.src.rpm

 Mandriva Linux 10.1:
 3ac90a3cd189ea0326d927370fdb250e  10.1/RPMS/sudo-1.6.8p1-1.3.101mdk.i586.rpm
 d0f1e39453c3efa42829959452b10f85  10.1/SRPMS/sudo-1.6.8p1-1.3.101mdk.src.rpm

 Mandriva Linux 10.1/X86_64:
 e4522d2cc1241b549143cdfd384b1e84  
x86_64/10.1/RPMS/sudo-1.6.8p1-1.3.101mdk.x86_64.rpm
 d0f1e39453c3efa42829959452b10f85  
x86_64/10.1/SRPMS/sudo-1.6.8p1-1.3.101mdk.src.rpm

 Corporate 3.0:
 7f961e981298b0e17db2206b0c173c94  
corporate/3.0/RPMS/sudo-1.6.7-0.p5.2.3.C30mdk.i586.rpm
 541ec48ae7f199c9e02209552541c93a  
corporate/3.0/SRPMS/sudo-1.6.7-0.p5.2.3.C30mdk.src.rpm

 Corporate 3.0/X86_64:
 0baca1e5dd528d9a0746812c3f70b6aa  
x86_64/corporate/3.0/RPMS/sudo-1.6.7-0.p5.2.3.C30mdk.x86_64.rpm
 541ec48ae7f199c9e02209552541c93a  
x86_64/corporate/3.0/SRPMS/sudo-1.6.7-0.p5.2.3.C30mdk.src.rpm

 Multi Network Firewall 2.0:
 73f5119120b2f173d2a5b529bc4b94b1  
mnf/2.0/RPMS/sudo-1.6.7-0.p5.2.3.M20mdk.i586.rpm
 6711bd6886115f5e5ec429eb739af719  
mnf/2.0/SRPMS/sudo-1.6.7-0.p5.2.3.M20mdk.src.rpm

 Mandriva Linux 10.2:
 d1145addcb3d305aa1149baaad74bee4  10.2/RPMS/sudo-1.6.8p1-2.2.102mdk.i586.rpm
 7cfd46cb455cc00b091849726d4763f5  10.2/SRPMS/sudo-1.6.8p1-2.2.102mdk.src.rpm

 Mandriva Linux 10.2/X86_64:
 9d59bab72f413dd21013add16252a48a  
x86_64/10.2/RPMS/sudo-1.6.8p1-2.2.102mdk.x86_64.rpm
 7cfd46cb455cc00b091849726d4763f5  
x86_64/10.2/SRPMS/sudo-1.6.8p1-2.2.102mdk.src.rpm

 Mandriva Linux 2006.0:
 bf2035af2ac556c3bcb013e80c4fbbd9  
2006.0/RPMS/sudo-1.6.8p8-2.1.20060mdk.i586.rpm
 4c708ebf20c38db338e909e6e461888f  
2006.0/SRPMS/sudo-1.6.8p8-2.1.20060mdk.src.rpm

 Mandriva Linux 2006.0/X86_64:
 569e58db33c0a58b0548e3ea699e86fa  
x86_64/2006.0/RPMS/sudo-1.6.8p8-2.1.20060mdk.x86_64.rpm
 4c708ebf20c38db338e909e6e461888f  
x86_64/2006.0/SRPMS/sudo-1.6.8p8-2.1.20060mdk.src.rpm
 ___

 To upgrade automatically use MandrivaUpdate or urpmi.  The verification
 of md5 checksums and GPG signatures is performed automatically for you.

 All packages are signed by Mandriva for security.  You can obtain the
 GPG public key of the Mandriva Security Team by executing:

  gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98

 You can view other update advisories for Mandriva Linux at:

  http://www.mandriva.com/security/advisories

 If you want to report vulnerabilities, please contact

  security_(at)_mandriva.com
 ___

 Type Bits/KeyID Date   User ID
 pub  1024D/22458A98 2000-07-10 Mandriva Security Team
  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDYSHOmqjQ0CJFipgRAhsFAKCvJg0ITGiwt0O/0MIrgel7XzsnWwCfWI6V
Gg3ko/2ajzrqIcE0Dz+QL0s=
=weOX
-END PGP SIGNATURE-
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Question about ethics when discovering a security fault in system

[Jeremy Bishop]

On Thursday 27 October 2005 11:28, Torbjörn Samuelsson wrote:
> Hi
>
> I stumbled upon a security fault (discovered it by mistake) this
> Sunday in a perimeter security device.
> The day after I contacted the manufacturer and informed them about it
> and later that evening the acknowledged the problem and they where
> able to reproduce it.

This sounds like a decent response time.  Was it a "we looked into this 
and it seems you are correct" response that you received, or something 
closer to "yeah, we already know about that and don't really care"?

> My question is what is good ethics for me to continue with this?

> What I want a resolution so the device we bought to provide us with
> remote access and security shall work securely and that the company

So, you are also a customer?  This gives you excellent grounds for 
asking how the company plans to correct this flaw.  Since it seems 
their initial response was both prompt and favorable, it's likely that 
some sort of update will be made available.  Your responsibility is to 
find a way to mitigate the current risk to your company until a fix is 
in place.  This usually includes allowing some time for the company to 
produce such a fix.  Going immediately public with the flaw is less 
than polite to the company, and will also jeopardize your own company.  
(I.e. People will now not only about the flaw, but about someone who is 
vulnerable to it: you.)

> shall inform other owner of there products about the problem so they
> wont have the same security breach.

It is possible that the company may do this on their own.  You don't 
have a responsibility to their other customers, only a more generalized 
responsibility to the community.  Custom on this list is that the 
vulnerability is revealed after a reasonable time.  "Reasonable" is a 
balance between allowing the vendor to produce a fix (so that when the 
problem is announced, people aren't needlessly exposed) and alerting 
the community to a problem (because it's likely someone else already 
knows about the problem, and is exploiting it).

Jeremy

-- 
...would you work for a company that couldn't tell the difference in
quality of its employees' normal work product and the work product of
someone on drugs without performing a test?
  -- socks
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] MDKSA-2005:200 - Updated apache-mod_auth_shadow packages fix security restriction bypass issues.

[Mandriva Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___
 
 Mandriva Linux Security Advisory MDKSA-2005:200
 http://www.mandriva.com/security/
 ___
 
 Package : apache-mod_auth_shadow
 Date: October 27, 2005
 Affected: 10.1, 10.2, 2006.0
 ___
 
 Problem Description:
 
 The mod_auth_shadow module 1.0 through 1.5 and 2.0 for Apache with 
 AuthShadow enabled uses shadow authentication for all locations that
 use the require group directive, even when other authentication
 mechanisms are specified, which might allow remote authenticated users
 to bypass security restrictions.
 
 This update requires an explicit "AuthShadow on" statement if website 
 authentication should be checked against /etc/shadow.
 
 The updated packages have been patched to address this issue.
 ___

 References:
 
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2963
 ___
 
 Updated Packages:
 
 Mandriva Linux 10.1:
 528cdab76158def18a53ce798f06efbf  
10.1/RPMS/apache2-mod_auth_shadow-2.0.50_2.0-3.2.101mdk.i586.rpm
 670e7f53e4d7ec420cc0ce529a11a423  
10.1/SRPMS/apache2-mod_auth_shadow-2.0.50_2.0-3.2.101mdk.src.rpm

 Mandriva Linux 10.1/X86_64:
 43f45a988397a72e7a00485055f00ca1  
x86_64/10.1/RPMS/apache2-mod_auth_shadow-2.0.50_2.0-3.2.101mdk.x86_64.rpm
 670e7f53e4d7ec420cc0ce529a11a423  
x86_64/10.1/SRPMS/apache2-mod_auth_shadow-2.0.50_2.0-3.2.101mdk.src.rpm

 Mandriva Linux 10.2:
 aa10a068cf7bc453cd8935b48afed141  
10.2/RPMS/apache2-mod_auth_shadow-2.0.53_2.0-6.2.102mdk.i586.rpm
 c7d15fcb80581c1169366d6ae56f9a1c  
10.2/SRPMS/apache2-mod_auth_shadow-2.0.53_2.0-6.2.102mdk.src.rpm

 Mandriva Linux 10.2/X86_64:
 caa1cb7195baf33a5ea8e07f31a84825  
x86_64/10.2/RPMS/apache2-mod_auth_shadow-2.0.53_2.0-6.2.102mdk.x86_64.rpm
 c7d15fcb80581c1169366d6ae56f9a1c  
x86_64/10.2/SRPMS/apache2-mod_auth_shadow-2.0.53_2.0-6.2.102mdk.src.rpm

 Mandriva Linux 2006.0:
 e720a14ca9e445ae9aca32a8bd077f59  
2006.0/RPMS/apache-mod_auth_shadow-2.0.54_2.0-4.1.20060mdk.i586.rpm
 29be94c1a29d1c1400d84781fe25fd2d  
2006.0/SRPMS/apache-mod_auth_shadow-2.0.54_2.0-4.1.20060mdk.src.rpm

 Mandriva Linux 2006.0/X86_64:
 19778e61e14975aa3f749068d985cf34  
x86_64/2006.0/RPMS/apache-mod_auth_shadow-2.0.54_2.0-4.1.20060mdk.x86_64.rpm
 29be94c1a29d1c1400d84781fe25fd2d  
x86_64/2006.0/SRPMS/apache-mod_auth_shadow-2.0.54_2.0-4.1.20060mdk.src.rpm
 ___

 To upgrade automatically use MandrivaUpdate or urpmi.  The verification
 of md5 checksums and GPG signatures is performed automatically for you.

 All packages are signed by Mandriva for security.  You can obtain the
 GPG public key of the Mandriva Security Team by executing:

  gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98

 You can view other update advisories for Mandriva Linux at:

  http://www.mandriva.com/security/advisories

 If you want to report vulnerabilities, please contact

  security_(at)_mandriva.com
 ___

 Type Bits/KeyID Date   User ID
 pub  1024D/22458A98 2000-07-10 Mandriva Security Team
  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDYSF4mqjQ0CJFipgRApMhAJwOhHZTL6cM5QtWXwPx7b2UUm+QOwCfTUNS
vCWmnkfd7AbnuJXCDlTZMVk=
=791Z
-END PGP SIGNATURE-
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Question about ethics when discovering a security fault in system

[Torbjörn Samuelsson]

Hi

I stumbled upon a security fault (discovered it by mistake) this Sunday 
in a perimeter security device.
The day after I contacted the manufacturer and informed them about it 
and later that evening the acknowledged the problem and they where able 
to reproduce it.


My question is what is good ethics for me to continue with this? Sense I 
discovered it by mistake, and everyone can do the same thing and 
everyone can reproduce it. And it is a perimeter security device 
providing remote access from a large manufacturer. And might be a known 
problem by others than the manufacturer, how ever the product has only 
bean on the market for about 2 months.


What I want a resolution so the device we bought to provide us with 
remote access and security shall work securely and that the company 
shall inform other owner of there products about the problem so they 
wont have the same security breach.


BR Tobbe


smime.p7s
Description: S/MIME Cryptographic Signature
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Re: Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through forged magic byte

[Thierry Zoller]

Dear James,

WJK> You are effectively altering existing viruses to the point that
WJK> AV scanners do not detect them.
No, he is changing a few bytes only.

WJK>  If your altered virus sample
WJK> still executes correctly, you have simply created a new virus 
WJK> variant.
No, there is no variant, the virus executes EXACTLY as before. A
variant acts differenlty then a precedent version, else it would be no
variant. To your AV engine it is a variant, yes, but only because it is flawed.

WJK> Consequently, the issue that you describe is *not* a
WJK> vulnerability issue, but rather just an example of a new variant
WJK> that has not yet been added to an AV vendor's database of "known
WJK> viruses".

Thank you James, this _to my knowledge_ (perhaps the guy from vmyths
knows better) is the first time the complete failure of todays AV
solutions is shown naked publicaly directly by a representant of an
AV company. This statement coming from a AV vendor is
simply exposing what is known in the sec. community since many years.

Instead of beahviour analysis, most AV vendors choose uterly stupid
PE section fingerprints, defeated by adding a few bytes. Go figure. of
course this is no vulnerability, it's a feature!

My theory on this is simple :
- ALL files can't be analysed the same way by AV engines (due to speed
  issues) (In other words not all analysis/fingerpritns is applied to
  every file)
  
The solution was to make the engines a bit "smarter", i.e analyse the
header to determine the type and then ONLY apply the signatures/heuristics
which apply to the type of the file (i am not speaking about the extension
of the file here) thus speeding up the process. Changing the header
just makes the smart engines look...well...  a bit dumb in my regards.

-- 
Regards,
Thierry Zoller
http://thierry.sniff-em.com


___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Secunia Research: ATutor Multiple Vulnerabilities

[Secunia Research]

==

 Secunia Research 27/10/2005

  - ATutor Multiple Vulnerabilities -

==
Table of Contents

Affected Software1
Severity.2
Vendor's Description of Software.3
Description of Vulnerabilities...4
Solution.5
Time Table...6
Credits..7
About Secunia8
Verification.9

==
1) Affected Software

ATutor 1.5.1-pl1

Other versions may also be affected.

==
2) Severity

Rating: Highly critical
Impact: System access, exposure of sensitive information, and
cross-site scripting
Where:  Remote

==
3) Vendor's Description of Software

ATutor is an Open Source Web-based Learning Content Management System 
(LCMS) designed with accessibility and adaptability in mind.

Product link:
http://atutor.ca/

==
4) Description of Vulnerabilities

Secunia Research has discovered some vulnerabilities in ATutor, which 
can be exploited by malicious people to conduct cross-site scripting 
attacks, disclose sensitive information, and compromise a vulnerable 
system.

1) Input passed to the "addslashes", "asc", and "desc" parameters in 
"include/html/forum.inc.php" isn't properly verified, before it is 
used to create a function call. This can be exploited to call an 
arbitrary PHP function with an arbitrary parameter (e.g. execute 
arbitrary shell commands with the "exec" function).

Examples:
http://[host]/include/html/forum.inc.php?
addslashes=[function]&asc=[parameter]
http://[host]/include/html/forum.inc.php?
addslashes=[function]&desc=[parameter]

Successful exploitation requires that "register_globals" is enabled.

2) Input passed to the "section" parameter in "body_header.inc.php" 
and "print.php" isn't properly verified, before it is used to include 
files. This can be exploited to include arbitrary files from local 
resources.

Examples:
http://[host]/documentation/common/body_header.inc.php?
section=[file]%00
http://[host]/documentation/common/print.php?section=[file]%00

Successful exploitation requires that "register_globals" is enabled 
and that "magic_quotes_gpc" is disabled.

3) Input passed to the "_base_href" parameter in 
"admin/translate.php", the "_base_path" parameter in 
"include/html/editor_tabs/news.inc.php", and the "p" parameter in 
"documentation/add_note.php" isn't properly sanitised before being  
returned to the user. This can be exploited to execute arbitrary 
HTML and script code in a user's browser session in context of an 
affected site.

The vulnerabilities have been confirmed in version 1.5.1-pl1. Other 
versions may also be affected.

==
5) Solution

Apply patch.
http://atutor.ca/view/3/6158/1.html

The fixes will also be included in the upcoming 1.5.2 version.

==
6) Time Table

10/10/2005 - Vulnerability discovered.
11/10/2005 - Vendor notified.
27/10/2005 - Vendor releases patch.
27/10/2005 - Public disclosure.

==
7) Credits

Discovered by Andreas Sandblad, Secunia Research.

==
8) About Secunia

Secunia collects, validates, assesses, and writes advisories regarding
all the latest software vulnerabilities disclosed to the public. These
advisories are gathered in a publicly available database at the
Secunia website:

http://secunia.com/

Secunia offers services to our customers enabling them to receive all
relevant vulnerability information to their specific system
configuration.

Secunia offers a FREE mailing list called Secunia Security Advisories:

http://secunia.com/secunia_security_advisories/

==
9) Verification

Please verify this advisory by visiting the Secunia website:
http://secunia.com/secunia_research/2005-55/advisory/

==




___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and 

Re: [Full-disclosure] Re: phpBB 2.0.17 (and other BB systems as well) Cookie disclosure exploit.

[Nicob]

Le jeudi 27 octobre 2005 à 08:54 -0500, Tatercrispies a écrit :

> And I really don't see how this could ever be used to execute
> server-side script unless for some bizarre reason you had your
> webserver so completely misconfigured as to be beyond imagination. Why
> would you be parsing image files through the PHP interpreter.

Please look at http://shsc.info/FileUploadSecurity#titelanker5 ...
And yes, it happens in real life scenarios !


Nicob

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] [CIRT.DK] - Novell ZENworks Patch Management Server 6.0.0.52 - SQL injection

[CIRT.DK Advisory]

The Novell ZENworks Patch Management Server 6.0.0.52 is vulnerable to 
SQL injection in the management console.

To being able to exploit this issue the administrator have to 
manually created a none-privileged account as minimum, to allow
exploitation.

Fix:
Upgrade to ZENworks Patch Management version 6.2.2.181
(or newer hot fix via your PLUS server) found at http://download.novell.com.

Note:   
The 6.0.0.52 CD ISO image was on the Novell download site up until the 2nd
week of September, 2005. 
The ZENworks Patch Management CD ISO image that is currently available at
the download site at the 
time of this document being published
http://download.novell.com/Download?buildid=5_kRStyf9wU~ 

ISO Name:   ZEN_PatchMgmt_Upd6.2.iso Size: 323.8 MB
(339607552) MD5: aeb244ecdf29c83cb8388fae1a6a1919 


A technical description of the vulnerability can be read at: 
http://www.cirt.dk



___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

RE: [Full-disclosure] Skype security advisory

[. EADS CCR DCR/STI/C]

On Wed, 26 Oct 2005, Brown, Bobby (US - Hermitage) wrote:

> I have the question, can the exploit be perform with no interaction of
> the user other than having the program running waiting for a connection
> or is it only valid after a user accepted a connection and then the flaw
> is exploited?

You don't need any user interaction. It works like any heap overflow (and 
even better because you can directly overwrite some function's pointers
without needing help from the heap management (unlink and friends)).

Because a single UDP packet can exploit the flaw, source can be spoofed 
and doesn't even have to be an IP/port the client has already spoken to.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] annoying bug in Windows XP

[Micheal Espinola Jr]

Microsoft feels your pain Georgi.  And just for you they are doing
something about it.

http://msexp.streamnavig.com/msexp/player.asp?e=E&s=_en_w&f=_en&uid=00011908A0C27CF6&lng=en&cou=emea


On 10/23/05, Georgi Guninski <[EMAIL PROTECTED]> wrote:
> sure it is a feature, not a bug.
>
> at http://en.wikiquote.org/wiki/Bill_Gates
> your idol wrote:
> "There are no significant bugs in our released software that any significant
> number of users want fixed."
>
>* Source: Focus Magazine, nr.43, pages 206-212, (October 23, 1995)
>
> a female melinda is rumored to have said:
>
> "for every chick 8.3cm. is long enough iff it is not macro and not hard"
>
> --
> where do you want bill gates to go today?
>
>
>
> On Sun, Oct 16, 2005 at 08:53:18AM -0400, joe wrote:
> > Yep it is a documented function. It is due to the implementation of
> > FindFirstFile which searches both long file names and short file names.
> >
> > See Remarks in
> >
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/f
> > indfirstfile.asp
> >
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>


--
ME2  
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] SEC-Consult SA 20051025-0 :: Snoopy Remote Code Execution Vulnerability

[SEC Consult Research]

On Thu, October 27, 2005 10:12 am, Florian Weimer said:
> Have you considered in your analysis that malicious servers might
> return HTTP redirects which contain suitable URLs?  This requires that
> the offsiteok member is set to true, though, because in the version I
> looked at, only http:// URLs are considered site-local.

Yes, I can confirm this. While I have not thought of this possibility, it
seems to boost the risk coming from the vulnerability.

I found the flaw during a review of Wordpress which uses MagpieRSS which
in turn uses Snoopy. As MagpieRSS is widly used, the concequence is that
any RSS feed-provider can replace the feed with a small redirect script,
exploiting the flaw with a crafted redirect https URL. Doing this with a
highly frequented RSS feed might result in many many servers being
simultaniously compromized. I might add that the offsiteok member defaults
to true and MagpieRSS does not seem to change that default value.

A notice to MagpieRSS has already been sent.

Daniel



~
SEC Consult Unternehmensberatung GmbH

Office Vienna
Blindengasse 3
A-1080 Wien
Austria

Tel.: +43 / 1 / 409 0307 - 570
Fax.: +43 / 1 / 409 0307 - 590
Mail: office at sec-consult dot com
www.sec-consult.com

EOF Daniel Fabian / @2005
d.fabian at sec-consult dot com



___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Re: phpBB 2.0.17 (and other BB systems as well) Cookie disclosure exploit.

[Tatercrispies]

On 10/27/05, Nicob <[EMAIL PROTECTED]> wrote:
> Le mardi 25 octobre 2005 à 17:02 -0400, Paul Laudanski a écrit :
> >
> > Anyone have other ideas on this?  I've already implemented some code
> > to validate file input and its working.  But is this the right
> > approach?
>
> I'm not sure to understand what you're talking about but if you're
> trying to positively validate that file XYZ is an image and not a PHP
> file, you're asking for trouble :
>

If your web application provides a mechanisim for users to upload
photos then the best solution so far that I've found is this.

. If you are storing the file in the file system, log it with a
non-guessable filename, or better yet, outside the webroot.

. Govern all access to this image by directing access through a script
that acts as a proxy. Spit the binary data back out to the browser,
but make certain that you are setting the Content-Disposition:
attachment HTTP header. This will cause all direct hits to this file
to be downloaded to the client workstation rather than executing the
file in the context of the hosting domain, but still allow  tags
to function properly.

And this technique is applicable for any type of file upload your site
might be providing. Comments?

And I really don't see how this could ever be used to execute
server-side script unless for some bizarre reason you had your
webserver so completely misconfigured as to be beyond imagination. Why
would you be parsing image files through the PHP interpreter. We're
talking about two completely different issues
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Re: phpBB 2.0.17 (and other BB systems as well) Cookie disclosure exploit.

[Nicob]

Le mardi 25 octobre 2005 à 17:02 -0400, Paul Laudanski a écrit :
> 
> Anyone have other ideas on this?  I've already implemented some code
> to validate file input and its working.  But is this the right
> approach?

I'm not sure to understand what you're talking about but if you're
trying to positively validate that file XYZ is an image and not a PHP
file, you're asking for trouble :

$> wget http://nicob.net/mirrors/blowjob.jpg

$> file blowjob.jpg 
blowjob.jpg: JPEG image data, JFIF standard 1.0

$> tail -n 5 blowjob.jpg


$> php blowjob.jpg
[garbage] Linux dellyre 2.6.[...] jeu oct 27 15:21:31 CEST 2005 [...]


Nicob

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] [SECURITY] [DSA 876-1] New lynx-ssl packages fix arbitrary code execution

[Martin Schulze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 876-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
October 27th, 2005  http://www.debian.org/security/faq
- --

Package: lynx-ssl
Vulnerability  : buffer overflow
Problem type   : remote
Debian-specific: no
CVE ID : CVE-2005-3120

Ulf Härnhammar discovered a buffer overflow in lynx, a text-mode
browser for the WWW that can be remotely exploited.  During the
handling of Asian characters when connecting to an NNTP server lynx
can be tricked to write past the boundary of a buffer which can lead
to the execution of arbitrary code.

For the old stable distribution (woody) this problem has been fixed in
version 2.8.4.1b-3.2.

For the stable distribution (sarge) this problem has been fixed in
version 2.8.5-2sarge1 of lynx.

For the unstable distribution (sid) this problem will be fixed soon.

We recommend that you upgrade your lynx-ssl package.


Upgrade Instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 3.0 alias woody
- 

  Source archives:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2.dsc
  Size/MD5 checksum:  609 6256bc48e63d9120301c6bdae3316675

http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2.diff.gz
  Size/MD5 checksum:87627 69a835be9e783a6788fd3122ec4c51d4

http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b.orig.tar.gz
  Size/MD5 checksum:  2557510 053a10f76b871e3944c11c7776da7f7a

  Alpha architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_alpha.deb
  Size/MD5 checksum:  1617392 d07cb6f46da183ab5c66860d90dd48c5

  ARM architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_arm.deb
  Size/MD5 checksum:  1491792 b20c7575d54e86838ddeff94622ce5ff

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_i386.deb
  Size/MD5 checksum:  1447102 0707d60cdc076a9078ecd198d9e185c5

  Intel IA-64 architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_ia64.deb
  Size/MD5 checksum:  1769060 9f621d66228be950732846918afb9b22

  HP Precision architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_hppa.deb
  Size/MD5 checksum:  1559592 c2c35718ba34d173fadefd3ba428695b

  Motorola 680x0 architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_m68k.deb
  Size/MD5 checksum:  1410534 86eff29224e043788f98a02f4af20402

  Big endian MIPS architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_mips.deb
  Size/MD5 checksum:  1511892 7fa8c96a81238e524e870dee74d07fa4

  Little endian MIPS architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_mipsel.deb
  Size/MD5 checksum:  1507808 5c7db52ed5910884679ec9ecc8606593

  PowerPC architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_powerpc.deb
  Size/MD5 checksum:  1497302 f82ae7bc6ee25639bd8c18ab6c644fb5

  IBM S/390 architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_s390.deb
  Size/MD5 checksum:  1468622 72b310726d3baecfe26ba27ce9f9f46a

  Sun Sparc architecture:


http://security.debian.org/pool/updates/main/l/lynx-ssl/lynx-ssl_2.8.4.1b-3.2_sparc.deb
  Size/MD5 checksum:  1497394 83d65399cb15b48bcd9024f01e3f9400


  These files will probably be moved into the stable distribution on
  its next update.

- 
-
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security 
dists/stable/updates/main
Mailing list: debian-security-announce@lists.debian.org
Package info: `apt-cache show ' and http://packages.debian.org/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDYMtkW5ql+IAeqTIRAhVoAJ9pKNsWYMEXdsX5aYnTieyf2mfWDwCghaQx
sRbTeSzDd6Z0mIIXOZiyVq0=
=kg5R
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Ch

Re: [Full-disclosure] Multiple Vendor Anti-Virus Software DetectionEvasion Vulnerability through forged magic byte

[Eygene A. Ryabinkin]

> Especially in case of EXEs, AFAIK not all EXEs has the same 'MAGIC BYTE'
> (MZ). MZ only appears in the first two bytes of Win32 executable files.

 Just for the curiosity: if you'll change "MZ" to "ZM" then the 16-bit
executables (MZ and NE executables) will still run and 32-bit (PE) executables
will execute their DOS stub part. It will be very interesting to check if
such files will be detected as executables at all in all mentioned antiviruses
and what sections PE files will be examined.

 The 'MZ' -> 'ZM' hack is the old feature of MS-DOS loader that still lives in
WinXP (at least, didn't tested others, but believe that they also carry that
feature). That's what is called 'interoperability between various versions' ;)
-- 
 rea
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Re: Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through forged magic byte

[Andrey Bayora]

Dear Ken,


If your altered virus sample
still executes correctly, you have simply created a new virus
variant.


Not exactly, please look at this virustotal.com log
http://www.securityelf.org/updmagic.html

The altered (120 bytes prepended) TXT_* variant is STILL detected by your
product (CA), but when I change the first byte from "Z" to "M" - your product
fails (MZ_* variant).
I believe, that if I PREPEND 120 bytes to known virus and the virus is still
detected with the SAME signature - then I DID NOT create a new variant.
Now one more example: try to change the first byte "Z" in the TXT_* variant to
any value, but not to "M" - this virus will be detected, but when you
change to
"M", thus creating the .EXE magic byte - the variant is not detected !!!
My conclusion: the antivirus “thought” that the file is the executable type
instead of determining the file type by the extension.

That is my point, if you still think that your product is OK - do not do
anything.

Regards,
Andrey Bayora.


Quoting "Williams, James K" <[EMAIL PROTECTED]>:




Subject: Re: Multiple Vendor Anti-Virus Software Detection
Evasion Vulnerability through forged magic byte
From: "Andrey Bayora" 
Date: 2005-10-25 3:07:51

[...]

VULNERABLE vendors and software (tested):

[...]

3.  eTrust CA (ver 7.0.1.4, engine 11.9.1, vir sig. 9229)

[...]
DESCRIPTION:

The problem exists in the scanning engine - in the routine that
determines the file type. If some file types (file types tested
are .BAT, .HTML and .EML) changed to have the MAGIC BYTE of the
EXE files (MZ) at the beginning, then many antivirus programs
will be unable to detect the malicious file. It will break the
normal flow of the antivirus scanning and many existent and
future viruses will be undetected.


Andrey,

Thank you for the report.

You are effectively altering existing viruses to the point that
AV scanners do not detect them.  If your altered virus sample
still executes correctly, you have simply created a new virus
variant.  If your altered virus sample does not execute properly,
you have created nothing more than a corrupt virus sample.

Consequently, the issue that you describe is *not* a
vulnerability issue, but rather just an example of a new variant
that has not yet been added to an AV vendor's database of "known
viruses".

Note that CA eTrust Antivirus, when running in Reviewer mode,
should already detect these new variants.

Regards,
Ken

Ken Williams ; Dir. Vuln Research
Computer Associates ; 0xE2941985




___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] [SECURITY] [DSA 875-1] New OpenSSL packages fix cryptographic weakness

[Martin Schulze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 875-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
October 27th, 2005  http://www.debian.org/security/faq
- --

Package: openssl094
Vulnerability  : cryptographic weakness
Problem type   : remote
Debian-specific: no
CVE ID : CVE-2005-2969

Yutaka Oiwa discovered a vulnerability in the Open Secure Socket Layer
(OpenSSL) library that can allow an attacker to perform active
protocol-version rollback attacks that could lead to the use of the
weaker SSL 2.0 protocol even though both ends support SSL 3.0 or TLS
1.0.

The following matrix explains which version in which distribution has
this problem corrected.

oldstable (woody)  stable (sarge) unstable (sid)
openssl  0.9.6c-2.woody.8   0.9.7e-3sarge1  0.9.8-3
openssl 094  0.9.4-6.woody.4 n/a  n/a
openssl 095  0.9.5a-6.woody.6n/a  n/a
openssl 096   n/a   0.9.6m-1sarge1n/a
openssl 097   n/an/a0.9.7g-5

We recommend that you upgrade your libssl packages.


Upgrade Instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 3.0 alias woody
- 

  Source archives:


http://security.debian.org/pool/updates/main/o/openssl094/openssl094_0.9.4-6.woody.4.dsc
  Size/MD5 checksum:  624 2989b7b16a146a2f9a6ca52887bb2c3f

http://security.debian.org/pool/updates/main/o/openssl094/openssl094_0.9.4-6.woody.4.diff.gz
  Size/MD5 checksum:47116 a4db6a4e53d8f8703da86774768cb21c

http://security.debian.org/pool/updates/main/o/openssl094/openssl094_0.9.4.orig.tar.gz
  Size/MD5 checksum:  1570392 72544daea16d6c99d656b95f77b01b2d

  Alpha architecture:


http://security.debian.org/pool/updates/main/o/openssl094/libssl09_0.9.4-6.woody.4_alpha.deb
  Size/MD5 checksum:   445816 1eaa00c5cee084727d23a8169acdb705

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/o/openssl094/libssl09_0.9.4-6.woody.4_i386.deb
  Size/MD5 checksum:   358626 2d3f09ecac497180a01facea470c

  PowerPC architecture:


http://security.debian.org/pool/updates/main/o/openssl094/libssl09_0.9.4-6.woody.4_powerpc.deb
  Size/MD5 checksum:   378870 58d0d41fa2005b5d05f49c557023c466


  These files will probably be moved into the stable distribution on
  its next update.

- 
-
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security 
dists/stable/updates/main
Mailing list: debian-security-announce@lists.debian.org
Package info: `apt-cache show ' and http://packages.debian.org/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDYJZpW5ql+IAeqTIRAu8zAKCZKeTsbp18kD+6dpno+xAvlT0D6gCguh3H
DQcg5cxf+sHJbhk4pT5uzBg=
=znal
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] SEC-Consult SA 20051025-0 :: Snoopy Remote Code Execution Vulnerability

[Florian Weimer]

* Bernhard Mueller:

> While the vulnerability can not be exploited using the Snoopy class
> file itself, there may exist implementations which hand unchecked
> URLs from users to snoopy.

Thanks for the notice.  

Have you considered in your analysis that malicious servers might
return HTTP redirects which contain suitable URLs?  This requires that
the offsiteok member is set to true, though, because in the version I
looked at, only http:// URLs are considered site-local.

(Note: I haven't tried to exploit this, I just browsed the code.)
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] [SECURITY] [DSA 874-1] New lynx packages fix arbitrary code execution

[Martin Schulze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 874-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
October 27th, 2005  http://www.debian.org/security/faq
- --

Package: lynx
Vulnerability  : buffer overflow
Problem type   : remote
Debian-specific: no
CVE ID : CVE-2005-3120

Ulf Härnhammar discovered a buffer overflow in lynx, a text-mode
browser for the WWW that can be remotely exploited.  During the
handling of Asian characters when connecting to an NNTP server lynx
can be tricked to write past the boundary of a buffer which can lead
to the execution of arbitrary code.

For the old stable distribution (woody) this problem has been fixed in
version 2.8.4.1b-3.3.

For the stable distribution (sarge) this problem has been fixed in
version 2.8.5-2sarge1.

For the unstable distribution (sid) this problem will be fixed soon.

We recommend that you upgrade your lynx package.


Upgrade Instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 3.0 alias woody
- 

  Source archives:

http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3.dsc
  Size/MD5 checksum:  579 117f4e3d95a601741dc672012719042c

http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3.diff.gz
  Size/MD5 checksum:14448 5e5d819520415baa0d91f75f0ee4f0af

http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b.orig.tar.gz
  Size/MD5 checksum:  2557510 053a10f76b871e3944c11c7776da7f7a

  Alpha architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_alpha.deb
  Size/MD5 checksum:  1610266 c887b1d0598b99fe1e3f45fedaaf3321

  ARM architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_arm.deb
  Size/MD5 checksum:  1487698 fb290d8440ef3b2b59f10e270b1d7bb6

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_i386.deb
  Size/MD5 checksum:  1442878 31da62cb1f065acc2f65f2fd4481d530

  Intel IA-64 architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_ia64.deb
  Size/MD5 checksum:  1762578 e57e52ed11ea52b55d6a5ede09b466a8

  HP Precision architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_hppa.deb
  Size/MD5 checksum:  1555440 4beb62a33cc2c0f00a45e69bed8b5591

  Motorola 680x0 architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_m68k.deb
  Size/MD5 checksum:  1405626 7f8d46f3d143781364337b666a55fa42

  Big endian MIPS architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_mips.deb
  Size/MD5 checksum:  1507782 ae2ce1ddbe4855967d050a3e64e42e26

  Little endian MIPS architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_mipsel.deb
  Size/MD5 checksum:  1503970 08e80c500a4d57a4e47fc45dbf0ebfe3

  PowerPC architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_powerpc.deb
  Size/MD5 checksum:  1491262 2b58dece4ae0a8a98b31e2f8eba40d13

  IBM S/390 architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_s390.deb
  Size/MD5 checksum:  1463360 1e5419b8db89374ea1c96f1219fe6e15

  Sun Sparc architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.4.1b-3.3_sparc.deb
  Size/MD5 checksum:  1492728 f4da20fe1ac83ee9adf37d49bb896c63


Debian GNU/Linux 3.1 alias sarge
- 

  Source archives:

http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.5-2sarge1.dsc
  Size/MD5 checksum:  614 e7d5a14aafd2e9775c3175e44e3f9964

http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.5-2sarge1.diff.gz
  Size/MD5 checksum:14891 59cf146b8defbfa1b78df4306b951441
http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.5.orig.tar.gz
  Size/MD5 checksum:  2984352 5f516a10596bd52c677f9bfd9579bc28

  Alpha architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.5-2sarge1_alpha.deb
  Size/MD5 checksum:  1994554 8a9eb6cd8ee34ad17aa06b912b588659

  AMD64 architecture:


http://security.debian.org/pool/updates/main/l/lynx/lynx_2.8.5-2sarge1_amd64.deb
  Size/MD5 checksum:  188

[Full-disclosure] Re: Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through forged magic byte

[Williams, James K]

> Subject: Re: Multiple Vendor Anti-Virus Software Detection 
> Evasion Vulnerability through forged magic byte
> From: "Andrey Bayora" 
> Date: 2005-10-25 3:07:51
>
> [...]
>
> VULNERABLE vendors and software (tested):
>
> [...]
>
> 3.  eTrust CA (ver 7.0.1.4, engine 11.9.1, vir sig. 9229)
>
> [...]
> DESCRIPTION:
>
> The problem exists in the scanning engine - in the routine that
> determines the file type. If some file types (file types tested
> are .BAT, .HTML and .EML) changed to have the MAGIC BYTE of the 
> EXE files (MZ) at the beginning, then many antivirus programs 
> will be unable to detect the malicious file. It will break the 
> normal flow of the antivirus scanning and many existent and 
> future viruses will be undetected.

Andrey,

Thank you for the report.  

You are effectively altering existing viruses to the point that 
AV scanners do not detect them.  If your altered virus sample 
still executes correctly, you have simply created a new virus 
variant.  If your altered virus sample does not execute properly, 
you have created nothing more than a corrupt virus sample.

Consequently, the issue that you describe is *not* a 
vulnerability issue, but rather just an example of a new variant
that has not yet been added to an AV vendor's database of "known
viruses".

Note that CA eTrust Antivirus, when running in Reviewer mode, 
should already detect these new variants.

Regards,
Ken 
   
Ken Williams ; Dir. Vuln Research 
Computer Associates ; 0xE2941985

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Multiple Vendor Anti-Virus Software DetectionEvasion Vulnerability through forged magic byte

[Andrey Bayora]

I checked the "ZM" variant and got the same results as for "MZ" one.
Thus, I think that they indeed, detected as executables, but only AV vendor
can tell for sure.
Generally, there are many variants for this issue, as many various "magic
byte" variants exist.
In my case - I force AV to look at the TEXT file as to EXECUTABLE, but it's
possible that other "pairs" then txt<->exe exist as well.

Regards,
Andrey Bayora.



- Original Message - 
From: "Eygene A. Ryabinkin" <[EMAIL PROTECTED]>
To: "Debasis Mohanty" <[EMAIL PROTECTED]>
Cc: "'Andrey Bayora'" <[EMAIL PROTECTED]>;
; 
Sent: Thursday, October 27, 2005 8:25 AM
Subject: Re: [Full-disclosure] Multiple Vendor Anti-Virus Software
DetectionEvasion Vulnerability through forged magic byte


> > Especially in case of EXEs, AFAIK not all EXEs has the same 'MAGIC BYTE'
> > (MZ). MZ only appears in the first two bytes of Win32 executable files.
>
>  Just for the curiosity: if you'll change "MZ" to "ZM" then the 16-bit
> executables (MZ and NE executables) will still run and 32-bit (PE)
executables
> will execute their DOS stub part. It will be very interesting to check if
> such files will be detected as executables at all in all mentioned
antiviruses
> and what sections PE files will be examined.
>
>  The 'MZ' -> 'ZM' hack is the old feature of MS-DOS loader that still
lives in
> WinXP (at least, didn't tested others, but believe that they also carry
that
> feature). That's what is called 'interoperability between various
versions' ;)
> -- 
>  rea
>
>

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/