From owner-freebsd-security@freebsd.org Sun Sep 11 02:26:41 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AF43BCF409 for ; Sun, 11 Sep 2016 02:26:41 +0000 (UTC) (envelope-from selphie.keller@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1975BBEA for ; Sun, 11 Sep 2016 02:26:40 +0000 (UTC) (envelope-from selphie.keller@gmail.com) Received: by mail-oi0-x232.google.com with SMTP id y2so232781919oie.0 for ; Sat, 10 Sep 2016 19:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QZC313Q8sONOkaRNfkAvXYt3rWgCap3E0TjF8CwFzKs=; b=C7IZt/JJJ5+/K0cc4T3ddtPKW60EfFRSIb6stLei/grKDcYLb5WjcuBtfVk0dKHfjb 5xJZv6ib1pNtTH8JjPxNUmj0Y7X0dY1wqUByd9eNxkZEeaZHfRrHFeh5VGrlZFjTAAna oC4MRqCqO0NTIT0lyjuhs3ElMU1Dlcuq5AMk6fsCej2fSfUwtq+HDzy1Gbh6vaKbXSmm qCF2fns8uE8QvCbIVJlIyOz3a69CFMS/uJvoFPyhI1xxfIT3HOZbauO8gIq/Qn0UTw9k qE19Ul3gHeul6k72y4qxaP53dEOMZdhA/NKTDZ6qITTcP+BADp+U4DcmvpuxF7jBbfqv pWXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QZC313Q8sONOkaRNfkAvXYt3rWgCap3E0TjF8CwFzKs=; b=c6pIIjnCcin2+vBAhqgVSLtsa5cw/9mjFNBz7gG6gRg+5SPeIbiTWku3OUkmEubuDm GxDLP/YiYQ8Sa5PQb2yb4p52heDXUc3lGevNql1/DMVaIHhhEworyyC07v2dRBxkbhd8 1TElIqi9FpBQ7AUnlf0k0UnsQmmw4Rx98RYvASKxyNjewncoaFWuv2S/FMoGyCq4RHub EfP624yNpouMK+GBZjm8nFvrADFQ1KpRPUkBvA0Y8BqvY7k1yQUzliU0Sc2ToleOUz2j 9s5pCJ7ir2Z5h64Va+4usNsTxWNkautXedLbrj6DlVyGz48S3nNPw9laRAQql8fNdWHI Xusw== X-Gm-Message-State: AE9vXwMamUgPZTHvCmlPT2h2xhz3mCSQldn7FCIkeyhdogRsMYP51Rhphi2zuMnV+codsonu1gc+H3RHtxVm+Q== X-Received: by 10.157.43.4 with SMTP id o4mr12087716otb.139.1473560800198; Sat, 10 Sep 2016 19:26:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.12.196 with HTTP; Sat, 10 Sep 2016 19:26:39 -0700 (PDT) In-Reply-To: <40863.1473559289@server1.tristatelogic.com> References: <40863.1473559289@server1.tristatelogic.com> From: Selphie Keller Date: Sat, 10 Sep 2016 20:26:39 -0600 Message-ID: Subject: Re: Disinfecting attachments (?) To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2016 02:26:41 -0000 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 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 > " >