New (but really - old) Windows .lnk vulnerability
in [Viruses]
|
Prev: Anti-Virus Best one
Next: Win32/RAMNIT.A Anyone?
From: Ant on 25 Jul 2010 22:27 "FromTheRafters" wrote: > I see. I was just reacting to the "as published" .lnk file. The 'as > published' exploit may have been NT *vector* specific but not actually > exclusive (once ported) as a demonstatable vulnerability for 9x. You got me thinking more about this and I did further checks. I don't believe I did port the POC correctly to 9x - all I did was play around with the path but left it as unicode. I thought this form of ID list (PIDL) would be ok for 9x despite not supporting unicode in the API. It's all a bit confusing because there are many ways to construct a shortcut. There are different types, e.g. whether a virtual folder or real directory is in the path, and much of the content is optional. There are also differences between Win2k and XP in that, even when the unicode flag is set, real file paths and names in a W2k PIDL use ANSI, whereas the same on XP contains unicode. This is independent of the other data in the shorcut which seems always to appear as unicode on NT based systems. The 'special' form (it's not a standard way of storing a file path) of the POC PIDL is in unicode and is ok for NT4, W2k or XP. However, a similar shortcut (not a POC but a non-standard path) created on 95 is not unicode. I'm thinking it may well be possible to create an exploit for 9x (not that anyone is likely to bother) but I don't know enough about the undocumented internals of shell PIDLs to be able to duplicate it. The 9x internal structure is somewhat different and just changing the unicode flag and converting the string to ANSI is not enough.
From: FromTheRafters on 26 Jul 2010 16:48 "Dustin" <bughunter.dustin(a)gmail.com> wrote in message news:Xns9DC0E04C8A5CEHHI2948AJD832(a)69.16.185.250... > "FromTheRafters" <erratic(a)nomail.afraid.org> wrote in > news:i2igpt$ov3$1 > @news.eternal-september.org: > >>> I could have sworn this exploit had been discussed several years >>> ago... >> >> A decade in the case of format string attacks. > > I still blame lazy programmers for that. Seriously, how much more time > does it take a person to write the code to verify the buffer has > enough > room for the string; and to invalidate bad configuration data? :( All true. I remember writing input validation subroutines, seems the higher level programming languages allow sloppy programming while freeing the programmer from the mundane chores of optimizing code. Anyway, my only reason for the comparison was in how long resulting 'vulnerabilities' existed before being disclosed, not whether or not they were lazy programming errors or forgotten filetype backward compatibility functionality.
From: Dustin on 26 Jul 2010 18:44
"FromTheRafters" <erratic(a)nomail.afraid.org> wrote in news:i2ksah$t1p$1(a)news.eternal-september.org: > "Dustin" <bughunter.dustin(a)gmail.com> wrote in message > news:Xns9DC0E04C8A5CEHHI2948AJD832(a)69.16.185.250... >> "FromTheRafters" <erratic(a)nomail.afraid.org> wrote in >> news:i2igpt$ov3$1 >> @news.eternal-september.org: >> >>>> I could have sworn this exploit had been discussed several years >>>> ago... >>> >>> A decade in the case of format string attacks. >> >> I still blame lazy programmers for that. Seriously, how much more >> time does it take a person to write the code to verify the buffer >> has enough >> room for the string; and to invalidate bad configuration data? :( > > All true. I remember writing input validation subroutines, seems the > higher level programming languages allow sloppy programming while > freeing the programmer from the mundane chores of optimizing code. > > Anyway, my only reason for the comparison was in how long resulting > 'vulnerabilities' existed before being disclosed, not whether or not > they were lazy programming errors or forgotten filetype backward > compatibility functionality. > > > Good points... and well taken here. -- "I like your Christ. I don't like your Christians. They are so unlike your Christ." - author unknown. |