Disinfecting attachments (?)

Selphie Keller selphie.keller at gmail.com
Sun Sep 11 02:26:41 UTC 2016

WHMCS has had serious issues in the past with code execution,
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,
, 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,

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.


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

> 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-security at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org
> "

More information about the freebsd-security mailing list