Disinfecting attachments (?)

[Ronald F. Guilmette]

Maybe an ignorant question, but hopefully not an outright stupid one...

The story:

As I was interacting with my new VM provider, there was a problem.
And I had to send the provider a captured screenshot of the browser
window where something had gone ugly wrong.

I managed to get the screenshot as a .png file, and was all prepared
to attach it to a follow-up message that I was sending to the provider
through the providers's ticket system, which is apparently based on
WHMCS (which I confess I know nothing about).

Anyway, the try as I might, the ticket system kept refusing to allow
me to attach *any* attachment to my messages. I kept giving me the
following utterly moronic and useless error message:

The following errors occurred:
* The file you tried to upload is not allowed.

Subsequent queries to the provider elicited the following explanation:

"Oh, the attachments are disabled as a security precaution - it's
unfortunate, but WHMCS doesn't actually 'check' attachments for
malicious files, so it's a potential point of compromise."

Now, please understand everybody, as a general matter I actively _avoid_
using Windoze whenever possible. I'm proud to say that (a) I've never
in my life read a single email message of my own on any Windoze system
and also (b) that I've never yet been hacked. (And yes, I do believe
that there may be a relationship between these two facts.)

My point is that I've never found it necessary to understand in any
depth what sorts of attachments could possibly do damage, e.g. if
opened in the Wrong Environment. My abundant ignorance gives rise
to the following seemingly simple and obvious question:

After all these years, and after thousands or millions of different
types and strains of malware having been seen in the wild, is there
really still no readily available tool that can simply be given a hunk
of data, sent as an email attatchment, and which can successfully
remove from that hunk of data any and all "active" elements, components,
or sub-parts which might even potentially cause damage in any arbitrary
environment?

If not, then perhaps I just invented the next billion dollar start up.
:-)

But seriously folks, if the first few bytes of a file say that it is
just a plain old ordinary .png file, then why would anybody or anything
live in fear of it? It's just a bloody image file for God's sake!

Ok, so I just googled around and found some articles describing some
reports of "exploits" ostensibly relating n some way to .png files.
But drilling down into those shows that really, all that is actually
happening here is that the attackers are using certain parts of .png
files... e.g. the tail end or the metadata fields... to smuggle in
_other_ bad stuff _after_ the attacker has already gotten control in
some other way.

So it seems that whereas .png files can be used for smuggling in evil
data, they can't really be used for primary exploitation. On that
basis alone I have no idea why anyone would ever think that it would
ever be of any use at all to block them. But even if the thought
of receiving a .png file makes you shrink in horror, why not just build
a tool which inspects the bloody things and which strips out any of
the unnatural/evil/smuggled content, leaving behind just an utterly
harmless toothless actual image file?

I tried googling for "attachment disinfection" but it appears that most
or all of the hits I get are to do with water purification and/or other
biology-related subjects.

So seriously, nobody ever built an attachment disinfector?


Regards,
rfg
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Selphie Keller]

WHMCS has had serious issues in the past with code execution,
https://www.cvedetails.com/vulnerability-list/vendor_id-10798/Whmcs.html
this is likely the provider just trying to avoid issues while using this
system. Many years back there was a nice exploit involving hiding php
shells inside PNG data chunks and that could be triggered via resizing and
other functions which led to the hacking of some forum software,
https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/
, in today's exploit world anything can be mundane at first then later
weaponized by some secondary payload/process this concept has been shown
with egghunter where arbitrary data is appended into a request as just
ascii then later transforms into shellcode, another case involved a person
that could use some clever AES transformations that could turn a wallpaper
into a payload apk just with AES decrypt on android,
http://securityaffairs.co/wordpress/29438/security/hiding-malicious-android-apk.html

So even if an attachment seemed safe there could be risk that it can be
transformed later into something else. Though, in this case I think it's
more about the provider using WHMCS and the issues it had in the past, so
they likely setup this policy to reduce some of those vectors of attack.

-Mystagic

On 10 September 2016 at 20:01, Ronald F. Guilmette <r...@tristatelogic.com>
wrote: