| 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
| ||
|
From: http-equiv at malware.com (http-equiv@...ite.com)
Subject: Re: UPDATE: Re: REFRESH: EUDORA MAIL 5.1.1
Nick FitzGerald <nick@...us-l.demon.co.uk> said:
> Jeff Kell <jeff-kell@....edu> replied to http-equiv@...ware.com:
>
> [I thought I replied to "http-equiv"'s message earlier, but on
> checking I sent it direct, not to the lists...]
>
> > > Just tested something here. Typically IE can or will open files
> > > depending what the contents are regardless of the extension
that it
> > > is: <html> tag in a gif or some other file type should or can be
> > > rendered by IE for what the contents are, not the extension.
> >
> > The Windows run function (IE viewer) ignores the extension (sort
of) if
> > the file is in a portable OLE-type format. For example, go in
Word and
> > create "foo.doc". Exit and rename "foo.doc" to "foo.fubar".
Double
> > click "foo.fubar" and Word opens up. Same for Excel and other
things.
> >
> > If the extension is known, it appears to try and use it. If not,
it
> > will look for OLE-extensions and launch what matches.
>
> It's the other way around -- if a file's extension is not registered
> on the system trying to "run" (or "open") the file, depending on
how
> it is being "opened", some further checks than just "what is
> registered to handle this extension" are made. One of those checks
> determines whether the file is apparently internally an OLE2 file,
> and if so the application registered to handle the CLSID of the
root
> directory entry in the OLE2 file is directed to open the file. If
> that CLSID is also not registered then the usual "Open With..."
> dialog appears. Another file type tested for in this process is
the
> DOS ("MZ") EXE format, which can be run "as normal", depending on
the
> "open" method used, depsite having been renamed to a non-EXE
> extension.
>
> Thus, "http-equiv"'s discovery that a non-extensioned EXE could be
> launched through one of these code execution holes is not all that
> surprising...
For clarity's sake, in this particular instance it was only the meta
refresh that was non-extensioned.
In the embedded folder we had / have:
malware.exe
malware [the mhtml file -- no extension]
<META http-equiv=refresh content="1;
url=file://C:\WINDOWS\Application
Data\Qualcomm\Eudora\Embedded\malware">
The refresh tag is pointing to malware -- what it does is skip over
the non-extensioned mhtml file, and instead, open malware.exe
directly.
--
http://www.malware.com
Powered by blists - more mailing lists