xmlrpc exploit

 Instructions

 hackers: go and exploit.
 admins: go and remove xmlrpc.php
 both: have fun

 ilo--

-----BEGIN PGP SIGNATURE-----
Charset: UTF8
Version: Hush 2.4

wkYEABECAAYFAkLEhzgACgkQyVWFTD0n8MJQDQCgsk6a6ksm203192k+4EgFjV5EHR4A
oK9IavxNE9LobSw3fJB+Oq6dCGDx
=QmBv
-----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: Publishing exploit code - what is it good for

1) Over a long period of time, after learning the different dimensions
of attack, PoC code can turn you into a pretty good pen tester of your
own network and setup.  We all learn from our mistakes.  You learn
nothing from a security alert with no details as to what exact mistake
was made in a product where others could learn from.
2) (in some cases) PoC code although temporarily causes harm, sometimes
overall improves internet security as a whole.  Look at MS blaster, we
all learned quick to patch the correct ports (well most of us) and now
use firewalls as well as Microsoft turning them on by default.
3) PoC code will get the vendor to take quick action.  With no poc, they
will take there little old time to patch their product.  They assume its
not being used in the wild, but how could anyone be so sure?

Michael Evanchik
www.michaelevanchik.com

-----Original Message-----
From: full-disclosure-bounces <at> lists.grok.org.uk
[mailto:full-disclosure-bounces <at> lists.grok.org.uk] On Behalf Of Aviram
Jenik
Sent: Thursday, June 30, 2005 8:14 AM
To: full-disclosure <at> lists.grok.org.uk; bugtraq <at> securityfocus.com
Subject: [Full-disclosure] Publishing exploit code - what is it good for

Hi,

I recently had a discussion about the concept of full disclosure with
one of 
the top security analysts in a well-known analyst firm. Their claim was
that 

[SECURITY] [DSA 735-1] New sudo packages fix pathname validation race

------------------------------------------------------------------------
Debian Security Advisory 735-1                       security <at> debian.org
http://www.debian.org/security/                            Michael Stone
July 01, 2005                         http://www.debian.org/security/faq
------------------------------------------------------------------------

Package        : sudo
Vulnerability  : pathname validation race
Problem type   : local
Debian-specific: no
CVE Id(s)      : CAN-2005-1993
Debian Bug     : 315115

A local user who has been granted permission to run commands via sudo
could run arbitrary commands as a privileged user due to a flaw in
sudo's pathname validation. This bug only affects configurations which
have restricted user configurations prior to an ALL directive in the
configuration file. A workaround is to move any ALL directives to the
beginning of the sudoers file; see the advisory at
http://www.sudo.ws/sudo/alerts/path_race.html for more information.

For the old stable Debian distribution (woody), this problem has been
fixed in version 1.6.6-1.3woody1. For the current stable distribution
(sarge), this problem has been fixed in version 1.6.8p7-1.1sarge1. Note
that packages are not yet ready for certain architectures; these will be
released as they become available.

We recommend that you upgrade your sudo package.

plz suggest security for DLL functions

friends, 

We are developing a software that makes use of a COM DLL. The whole
logic lies in the dll. The User Interface is in VC++. DLL exposes
functions, application calls it and displays result. Now, we found
that anybody can copy the DLL, register it and make use of those
functions.

Please guide us in making those functions secret or encrypted so that
others cannt use our functions.

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

Prevx Pro 2005 - Multiple Vulnerabilities

_______________________________________________
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: plz suggest security for DLL functions

> Please guide us in making those functions secret or encrypted so that
> others cannt use our functions.

Using Windows DLL APIs, normally only those functions exported by a
DLL can be called by a process that maps the DLL in its address space.
The simplest solution is not to export the functions which u do not
want to be used by other programs using conventional LoadLibrary and
GetProcAddress.. in that case u need some clever hack for ur own
application that maps the entire DLL in its address space implements
offset based calculation to find the address of ur unexported
functions in the DLL and return to it, though i havent implemented
these concept but i think it is quite possible and can do it if
required.

as far as encryption is concerned, u can encrypt ur DLL as per ur wish
and decrypt it from ur userland application before memory mapping.

In any case, the phrase "others cant use the function" is not realy
feasible as far as i am concerned.

btw. Gaurav, I suggest better do ur homework using google or something
similar before asking these questions cause it sounds clueless..

Regards,
- Abhisek

On 7/1/05, Gaurav Kumar <gkverma <at> gmail.com> wrote:
> friends,
> 
> We are developing a software that makes use of a COM DLL. The whole
> logic lies in the dll. The User Interface is in VC++. DLL exposes
> functions, application calls it and displays result. Now, we found
> that anybody can copy the DLL, register it and make use of those
> functions.
> 
> Please guide us in making those functions secret or encrypted so that
> others cannt use our functions.
> 
> thanks and regards,
> gaurav
> _______________________________________________
> 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: plz suggest security for DLL functions

if it would have been so simpler, i wouldnt have asked it here, 
the application design doesnt allow us to use the conventioal
loadlibray method. we need to export functions also and at the same
time protect from misuse.

regards,
gaurav

On 7/1/05, Abhisek Datta <abhisek.datta <at> gmail.com> wrote:
> > Please guide us in making those functions secret or encrypted so that
> > others cannt use our functions.
> 
> Using Windows DLL APIs, normally only those functions exported by a
> DLL can be called by a process that maps the DLL in its address space.
> The simplest solution is not to export the functions which u do not
> want to be used by other programs using conventional LoadLibrary and
> GetProcAddress.. in that case u need some clever hack for ur own
> application that maps the entire DLL in its address space implements
> offset based calculation to find the address of ur unexported
> functions in the DLL and return to it, though i havent implemented
> these concept but i think it is quite possible and can do it if
> required.
> 
> as far as encryption is concerned, u can encrypt ur DLL as per ur wish
> and decrypt it from ur userland application before memory mapping.
> 
> In any case, the phrase "others cant use the function" is not realy
> feasible as far as i am concerned.
> 
> btw. Gaurav, I suggest better do ur homework using google or something
> similar before asking these questions cause it sounds clueless..
> 
> Regards,
> - Abhisek
> 
> On 7/1/05, Gaurav Kumar <gkverma <at> gmail.com> wrote:
> > friends,
> >
> > We are developing a software that makes use of a COM DLL. The whole
> > logic lies in the dll. The User Interface is in VC++. DLL exposes
> > functions, application calls it and displays result. Now, we found
> > that anybody can copy the DLL, register it and make use of those
> > functions.
> >
> > Please guide us in making those functions secret or encrypted so that
> > others cannt use our functions.
> >
> > thanks and regards,
> > gaurav
> > _______________________________________________
> > 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: Publishing exploit code - what is it good for

Interesting, becuase this just hit me the other day.

Wearing my sysadmin hat, I woke up one morning to find that the NetBSD
package converters/xlreader had a vulnerability. Nobody seemed to have
a patch for it, but looking at it, even with my rather limited level of
C coding skill, I reckoned I could fix it. (Standard buffer overflow:
replace sprintf with snprintf kinda thing.) So I did.

Or at least, I think I did. I can't get my hands on a working exploit,
so I don't feel truly comfortable that I did indeed fix the problem. Maybe
to someone more familiar with C it would be proved fixed by inspection,
but I don't feel that comfortable with it myself.

I didn't really used to think that exploits were so useful until this.

cjs
--

-- 
Curt Sampson  <cjs <at> cynic.net>   +81 90 7737 2974   http://www.NetBSD.org
      Make up enjoying your city life...produced by BIC CAMERA
_______________________________________________
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: Publishing exploit code - what is it good for

I for one am glad to see PoC code. Too often vendors are very vague with 
their patchsets (Oracle basically says to install a huge tarball to fix 
'critical' vulnerabilities without listing exactly what it fixes and the 
recent Backup Exec vulnerability had a later patch version available for 
a different unrelated problem than the published advisory for the agent 
password overflow - you had to read three different advisories to find 
out if the later patchset had the fix - it did, even then it was a crap 
shoot). Given the lack of disclosure from the vendors, I like to have 
PoC code available to test if the patch really was applied correctly 
(and was the correct one). Don't forget the instances when either a 
patch silently fails, or if you are a security admin, don't trust that 
the admins really patched all of their machines. I would forgo most PoC 
codes if vendors would *exactly* explain what was in their patchsets 
(and provided a way to test for the existence of easily) and what they 
addressed without these matrix's of different versions of their product 
cross-referenced to a simple 'critical' reference. Even as vague as MS 
announcements are, they are still one of the better disclosing vendors 
when it comes to their announcements.

Then again, I like to learn from the PoC code to further my knowledge as 
how the inner workings of programs work and how much of a poor job 
someone did while coding it.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[SECURITY] [DSA 736-1] New spamassassin packages fix potential DOS

------------------------------------------------------------------------
Debian Security Advisory 736-1                       security <at> debian.org
http://www.debian.org/security/                            Michael Stone
July 01, 2005                         http://www.debian.org/security/faq
------------------------------------------------------------------------

Package        : spamassassin
Vulnerability  : mail header parsing error
Problem type   : remote DOS
Debian-specific: no
CVE Id(s)      : CAN-2005-1266
Debian Bug     : 314447

A vulnerability was recently found in the way that SpamAssassin parses
certain email headers. This vulnerability could cause SpamAssassin to
consume a large number of CPU cycles when processing messages containing
these headers, leading to a potential denial of service (DOS) attack. 

The version of SpamAssassin in the old stable distribution (woody) is
not vulnerable.

For the stable distribution (sarge), this problem has been fixed in
version 3.0.3-2. Note that packages are not yet ready for certain
architectures; these will be released as they become available.

For the unstable distribution (sid), this problem has been fixed in
version 3.0.4-1.

We recommend that you upgrade your sarge or sid spamassassin 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 3.1 (sarge)
------------------

  Source archives:

    http://security.debian.org/pool/updates/main/s/spamassassin/spamassassin_3.0.3-2.diff.gz
      Size/MD5 checksum:    44610 b1b383fc4f9dc0792ecd954fa99aaa56
    http://security.debian.org/pool/updates/main/s/spamassassin/spamassassin_3.0.3.orig.tar.gz
      Size/MD5 checksum:   999558 ca96f23cd1eb7d663ab55db98ef8090c
    http://security.debian.org/pool/updates/main/s/spamassassin/spamassassin_3.0.3-2.dsc
      Size/MD5 checksum:      776 4f3092c679992ad322598f4195f4800c

  Architecture independent packages:

    http://security.debian.org/pool/updates/main/s/spamassassin/spamassassin_3.0.3-2_all.deb
      Size/MD5 checksum:   768948 b2d7f49923aa67d8a016e5a3b3545249

  alpha architecture (DEC Alpha)

    http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_alpha.deb
      Size/MD5 checksum:    61552 84fcd819583c747545fda079a074d987

  i386 architecture (Intel ia32)

    http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_i386.deb
      Size/MD5 checksum:    58438 18138ce49c9d249fb5d93487e60481a2

  ia64 architecture (Intel ia64)

    http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_ia64.deb
      Size/MD5 checksum:    65020 65e214d1922317d511e23c32f7e19ff6

  m68k architecture (Motorola Mc680x0)

    http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_m68k.deb
      Size/MD5 checksum:    57536 b13aad3cb78a148e8838ddfdb301dbd5

  mips architecture (MIPS (Big Endian))

    http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_mips.deb
      Size/MD5 checksum:    60228 8578263361ff0e95ed0bddc2493d620e

  mipsel architecture (MIPS (Little Endian))

    http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_mipsel.deb
      Size/MD5 checksum:    60202 2338edb2f9679396005d490232147b7b

  powerpc architecture (PowerPC)

    http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_powerpc.deb
      Size/MD5 checksum:    60578 e547e452fc5e7ed28b04065af1b677a0

  s390 architecture (IBM S/390)

    http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_s390.deb
      Size/MD5 checksum:    59436 32ab8a7fef23ac35912ae51cc22aad29

  sparc architecture (Sun SPARC/UltraSPARC)

    http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_sparc.deb
      Size/MD5 checksum:    58370 8791b8226b25a0bc5381f39257ecd547

-------------------------------------------------------------------------------
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 <at> lists.debian.org
Package info: `apt-cache show <pkg>' and http://packages.debian.org/<pkg>