Full Disclosure mailing list archives
Re: A modest proposal
From: Gage Bystrom <themadichib0d () gmail com>
Date: Fri, 20 Jul 2012 18:11:36 -0700
If you are going to make a reference to something like the infamous A Modest Proposal, your post should have SOMETHING analogous to it, but that is besides the point :) Ok someone should correct me if I make a mistake on my next few points, because it has been a handful of months since I've mucked around with some of this stuff and I'm running off the top of my head here, but anyways: 1.) The ecosystem isn't going to get changed and become scrambled. That is outright counter-productive. I may have never been on a software development team, but anyone can look around and tell you it's hard enough to get a large application working consistently on even the majority of your target environments. Working with an environment intentionally scrambled to shore up the weaknesses of an idea that does not address the problem it's trying to would only make things infeasible. Security isn't worth it if the machine is a mere brick after words. Ergo hijacking DLLs will always work unless methods of stopping dll hijacking crop up(and I believe thats what code signing is useful for, but my memory is foggy right now). 2.) Yes my point is that blackbox(and grey box but you missed that, which is ok) tactics will not be bothered by it. Thats an issue because thats what people are already using anyways. Why implement a defense for something no one bothers with anyways? It'd be like safeguarding a room from Van Eck Phreaking when the only thing in the room is a headless server. 3.) Less callouts the better for the attacker in a way. Means less functions they need to monitor for, less things that need to be replaced. Also statically linked does not work well with ASLR, and supercharging it would only make things worse. ASLR works because code location cannot be predicted in advance, while almost by definition statically linked anything means everything HAS to be predictable. In fact on linux you can't statically link an executable and still make it a PIE'd executable. For the record PIE is essentially aslr actually in practice when it comes to the .text portion of the code. In hindsight it almost sounds like you are trying to argue for PIE but are going about it backwards. 4.) You don't need to reverse engineer each executable. Like I said, each program variant still has to have the same inputs and outputs and thats all a piece of malware needs to look for. The reason why malware uses these techniques is NOT to make reverse engineering harder or anything remotely of the nature, it's merely to prevent automated detection. A piece of malware doesn't necessarily have to have the same inputs and outputs because it does not exist for the sake of the end-user. Real applications have to, so they cannot employ those methods to escape automated detection by malware /because it will be defeated in ten seconds flat/. On a unrelated note, what the hell is everyone else talking about? You never mentioned anything about trying to stop bugs and exploits, only about preventing malware from interfering with the executable itself ala ZeuS. I imagine with the idea that doing so would force malware to use more obtruse methods that would make them be easier caught by traditional means. And your reply to me seems to confirm that, so I know I wasn't the one that misread you, but I'm weirded out that it seems like nearly everyone else did. On Fri, Jul 20, 2012 at 6:03 AM, Everhart, Glenn <glenn.everhart () chase com> wrote:
Well, the idea was not only to change instructions but change layout, heavily (ASLR on steroids). Some malware does that. It is of course much harder than just changing opcodes. (As for waste of a reference, how much do you expect in a quick message? J ) You are right that inputs and outputs of the program need to be the same. If however the ecosystem changes so that the OS and utilities all get massively scrambled, finding ways to replace those dlls can become harder to do. (Debugging does too, but you’d debug unscrambled, apply automated scrambling, and if that introduced errors you’d need to fix the scrambling process. There are tools I’ve seen references to for doing scrambling.) What you are pointing out is that black box techniques may continue to work. My point was that grey box and clear box techniques can be made hard. If the black box gets big enough (someday) the attacking business can get harder yet. (I was thinking of this in terms of a self contained program used for some fixed functions, and linking the whole mess statically the way portable executables get done, to minimize callouts.) Changing opcodes and so on makes it harder to find things though. Consider the case where you want to patch some entry point which is not global, so you haven’t got any nice pointer right into it. You find that normally by looking for code sequences. That’s not so easy when in effect there are no constant code sequences. Finding data is what you change layout for. There is no need to prevent reverse engineering. I thought that was clear enough: the point of the variation is that you make the attacker reverse engineer each copy separately. The attacker will get tired. It’s good to get responses like yours though; that is what I hoped might come out of the post. Glenn Everhart From: full-disclosure-bounces () lists grok org uk [mailto:full-disclosure-bounces () lists grok org uk] On Behalf Of Gage Bystrom Sent: Thursday, July 19, 2012 9:44 PM To: Glenn and Mary Everhart; full-disclosure () lists grok org uk Subject: Re: [Full-disclosure] A modest proposal 1.) waste of a reference by no follow through :( shame shame 2.) The only real problem with that idea is that you'd be doing it wrong. As in what you are doing does not accomplish what you want it to do. Those polymorphic techniques are there to prevent identification, not necessarily to prevent hooking, code injection, and reverse engineering. You use completely different techniques for those. 3.) It wouldn't be hard to get around it. Just replace a dll or two with the functions you want to intercept and analyze the output. They couldn't care less how polymorphic your code is if it still needs to pass the juicy data to a library function. And in a lot of cases they are already doing this, so its highly possible that you could suddenly take an application a piece of malware was designed to harvest information from, make it all polymorphic, and the same old malware version could still mess with it. And yes, it would still he able to identify the application cause the end user needs to be able to identify it and the malware would just use whatever method the end user would to spot it for injection or what not. 3.) I will say, at least you're thinking, even if its flawed. On Jul 19, 2012 6:24 PM, "Glenn and Mary Everhart" <everhart () gce com> wrote: Hello, FD... A thought occurred to me: Why not use the same kind of polymorphism and software metamorphism that is used by malware writers as a protective measure? If you have a piece of code that you don't want malware to be able to inspect, that might perhaps have some "secrets" in it or that you want not to be trivial to have some other code patch, why not arrange for that code to be different in form (but the same in function) with every copy? (For places that insist on code that must be signed, you might need to have only perhaps scores or hundreds of variants, and then make it clear that the "signed code" requirements were making the systems that have them LESS secure than those without. <bwahahaha>. <grin>.) There are many ways to achieve this kind of result. Many would result in somewhat larger executables or the like, or possibly larger data, but some of the methods don't even need access to source code. (I would suspect many systems like this will be clearest to those of us who have worked in assembly languages and the like over the years, but that is a bit beside the point.) If every copy of a program is laid out differently, and data gets moved around also from copy to copy, the job of the attacker would seem to get much harder. Glenn Everhart _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- A modest proposal Glenn and Mary Everhart (Jul 19)
- Re: A modest proposal Gage Bystrom (Jul 19)
- Message not available
- Re: A modest proposal Gage Bystrom (Jul 20)
- Message not available
- Re: A modest proposal Gage Bystrom (Jul 19)
- Re: A modest proposal valdis . kletnieks (Jul 19)
- Re: A modest proposal Memory Vandal (Jul 19)
- Re: A modest proposal Thor (Jul 20)
- Re: A modest proposal Christian Sciberras (Jul 20)
- Re: A modest proposal Thor (Jul 20)
- Re: A modest proposal Ben Laurie (Jul 20)
- Re: A modest proposal Bzzz (Jul 20)
- Re: A modest proposal Christian Sciberras (Jul 20)
- Re: A modest proposal valdis . kletnieks (Jul 20)
- Re: A modest proposal Jeffrey Walton (Jul 20)