Date: Sat, 10 Sep 2016 20:26:39 -0600 From: Selphie Keller <selphie.keller@gmail.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-security@freebsd.org Subject: Re: Disinfecting attachments (?) Message-ID: <CAAhz9Ok=p=N=Z=GjWABm1op70eGny4ZRhC2qD9yWn2yDq3bxZw@mail.gmail.com> In-Reply-To: <40863.1473559289@server1.tristatelogic.com> References: <40863.1473559289@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rfg@tristatelogic.com> wrote: > > 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAhz9Ok=p=N=Z=GjWABm1op70eGny4ZRhC2qD9yWn2yDq3bxZw>