full-disclosure - RE: Unchecked buffer in mstask.dll

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <FEBC66CCD411744381228574BAB53A9B803509@MAIL.fac.gatech.edu>
From: Justin.Polazzo at facilities.gatech.edu (Polazzo Justin)
Subject: RE: Unchecked buffer in mstask.dll

> (Hmmmm -- does it also fail on
W2K3??)

>I had to specifically click on the "Program" tab, which evoked a null-
>pointer read attempt
 
It works on 2k3, same steps taken.
 
jp

	-----Original Message----- 
	From: Nick FitzGerald [mailto:nick@...us-l.demon.co.uk] 
	Sent: Wed 7/14/2004 11:03 PM 
	To: bugtraq@...urityfocus.com; full-disclosure@...ts.netsys.com 
	Cc: 
	Subject: Re: [Full-Disclosure] RE: Unchecked buffer in mstask.dll
	
	

	"Jordan Cole (stilist)" <stilist@...il.com> to Paul Szabo:
	
	> > Being curious, on Win2k, I copied cmd.exe (from winnt\system32) as xyz.pif;
	> > then (right-click) Properties, Program crashes explorer.
	
	I had to specifically click on the "Program" tab, which evoked a null-
	pointer read attempt (at a guess, something in the .PIF parser assumes
	a length or offset will always be >0 so doesn't do any sanity checking,
	and/or some higher level routines don't do any checking).
	
	> I'd say that's because you changed the filetype; pif files simply
	> contain information on how to handle a DOS executable; they aren't a
	> program themselves. All you did was make it get confused and kill
	> itself.
	
	Yeah, but how long is it now since we've been telling programmers
	"don't trust user-supplied data"??  (Hmmmm -- does it also fail on
	W2K3??)
	
	And don't you also find the inconsistencies this throws up at least
	somewhat interesting?
	
	Rename a PE executable to a .PIF extension, right click, ask to see the
	file's properties and splat -- whatever code is invoked to handle that
	task dies a stupid, if not ugly, death because internally the file is
	the wrong type.  However, if you double-click that renamed file it is 
	executed as if nothing is amiss.
	
	And to think that some folk will see this as further reason to enforce
	their belief that when it comes to security and code quality, Microsoft
	really just doesn't get it...
	
	Why did MS make ".EXE files renamed as .PIF" execute "properly"?  Aside
	from "because we can", I'd not be at all surprised if it was on some
	internal "stupid user tricks we should eliminate support calls for"
	list.  But, whatever the reason, did anyone at Microsoft give two
	milliseconds of thought to the security (or other) consequences of that
	design decision?  I seriously doubt it and I'm sure I'm far from alone
	in that...
	
	
	--
	Nick FitzGerald
	Computer Virus Consulting Ltd.
	Ph/FAX: +64 3 3529854