Buffer Overflow Clarification

View previous topic View next topic Go down

Buffer Overflow Clarification

Post by Rico on 14/2/2011, 08:06

Ok I have read extensively about BO's. However there is one question that haunts my mind.
Are there 2 types of BO's?

i.e. one type exploits a browser (getting a foothold type) to download crap from the internet
While another is designed to cause the running app to act as the malicious exe itself ?

Is # 2 limited in terms of what kind of exploit is found in the program and the extent of actions it can undertake? Or does an exploit allow anything to happen?

Can a BO cause a legitimate browser to create files on the system on the behalf of shellcode? - provided nothing is downloaded


Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by MrBrian on 15/2/2011, 06:38

The shellcode could potentially do whatever the exploited program is allowed to do. There are some shellcode limitations though, such as space available, so often the shellcode downloads a file an executes it.

MrBrian
Member
Member

Posts : 14
Join date : 2010-07-01

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by Rico on 15/2/2011, 08:41

Since posting that question, I have done extensive research that yielded excellent results. I intend to post all the links that anwser these questions for this topic to serve as a future repository that will help people wanting to educate themselves.

Many of these links have Rmus' responses (very knowledgeable exploit researcher and analyst). Everything he utters in these threads is gold.

Thoughts on minimal security
http://www.wilderssecurity.com/showthread.php?t=283660

Any statistics on memory-only malware ?
http://www.wilderssecurity.com/showthread.php?t=291756

meterpreter
http://www.wilderssecurity.com/showthread.php?t=291814

Circumventing SRP and AppLocker by design, with LoadLibraryEx
http://www.wilderssecurity.com/showthread.php?t=291467&page=3

Adobe Reader/Acrobat Unspecified Buffer Overflow Vulnerability
http://www.wilderssecurity.com/showthread.php?t=233881

Buffer Overflow Attacks Unmasked
http://www.wilderssecurity.com/showthread.php?t=244430

applocker poc bypass (but no code)
http://www.wilderssecurity.com/showthread.php?p=1805915#post1805915

I would recommend reading everything in there to get the full picture but if not, I will summarize a few great points:

Shellcode mitigation from inital execution cannot be stopped by almost anything due to constant polymorphic and encryption tactics used.
What can be dealt with pretty well however is the payload executable that is downloaded either through readonly, AE and or firewall blocking of intial dropper if it exploits a non webfacing app ie PDF reader's internet connection to invite more malware.

On paper shellcode can potentially cause the exploited program to do anything on the system. However, Rmus has looked for such shellcode in vain till this day. Fortuneately 100% of shellcode in the wild can only be used as a drawabridge to get the actual virus executables in. The input validation of processes even if exploited heavily restricts the size of shellcode hence becoming a huge obstacle for blackhats. Where they can't fit the actual virus code to do the deed as only shellcode. Its simply too small of a space to work with.

In "Thoughts for minimal security" Rmus recommends using non default browsers such as Opera in his case with all plugins disabled. This has proven very effective against initial shellcode execution, virtually rendering all exploit urls he tested useless. Configuring a non default action of PDF viewers to ask beofre opening files was greatly recommended. By using non default browsers potential exploits would be non existent hence the shecllcode would find no foothold.

Regarding another point discussed was the abundance of DLL malware. According to Didier Stevens, the occurence of such malware is very common where the driveby would download and execute a DLL instead of exe. So mitigating DLL execution is a pretty serious affair.

Memory-only expoits are rare and targeted attacks at specific organizations that are meticulously planned. Its not cost effective and extremely hard to pulloff.



Last edited by Rico on 15/2/2011, 08:46; edited 1 time in total

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by ssj100 on 15/2/2011, 08:45

Rico, excellent post. Thanks.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Buffer Overflow Clarification

Post by Rico on 16/2/2011, 21:58

hi ssj, I read your question on the Sandboxie forums regarding memory only malware and found a good article to explain what exactly it is and its limitations: http://ezinearticles.com/?How-Can-I-Stop-Malware-That-Only-Lives-in-RAM?&id=4817612

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by ssj100 on 16/2/2011, 23:38

Hi Rico, which question was it? I can't really remember haha. Thanks for the link anyway.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Buffer Overflow Clarification

Post by Rico on 17/2/2011, 02:40

It was this part of your post that I meant to find an anwser for:

ssj100 wrote: I'm unsure how this would occur, but perhaps the buffer-overflow exploit would only need to take place in memory (via communicating with a malicious web-site). Step 2 is what I don't quite understand, but presumably "execution" could take place in memory also.

From the link above, it is quite evident that memory attacks have similar functionality limitations to shellcode. Its a good and reassuring read.

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by Rico on 17/2/2011, 06:37

On further reading of Rmus' description of what the Meterpreter Memory only POC does, it doesn't seem to do much:


Once this is done, the malware payload, Meterpreter, uses the target application as a host and lives within its memory space. Meterpreter offers the attacker the ability to migrate its code to another active process and to upload plug-ins that can be used to elevate privileges or to move laterally within the network.

This link gives information about the Meterpreter POC: http://www.offensive-security.com/metasploit-unleashed/Metasploit_About_Meterpreter
This one explains the DLL reflective technique that injects the code in memory only: http://www.harmonysecurity.com/ReflectiveDllInjection.html

Here is a list of the things it can do which again will be handicapped by AE and write protection of the target host : http://www.offensive-security.com/metasploit-unleashed/Metasploit_Meterpreter_Basics
The take home message here is; if it can't upload malicious files and execute them on the target machine, memory only malware like Meterpreter becomes pointless unless they intend to keylog.
Uploading virii to a compromised machine should fail if the sandbox is set as readonly C:\. The behavior of Meterpreter and similar payloads doesn't seem at all different from what shellcode normally does.

Using the Chrome browser will block code migration (thru memory) by design -- another reason why using an inherently secure browser is a biggie.

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by p2u on 17/2/2011, 09:46

Rico wrote:In "Thoughts for minimal security" Rmus recommends using non default browsers such as Opera in his case with all plugins disabled.
One more time I'd like to point out why: Not only do you get the browser warning, but if you haven't set any "outbound allow" firewall rules for the "plugged-in" applications, your firewall will block the traffic or at least ask you what to do. That's 2 layers of defense before your anti-executable is supposed to kick in to stop downloaded malicious executables from launching (that is: if you're lucky).
P.S.: Do not apply any firewall vendor's white lists to "automatically allow all Trusted applications out"! Convenience and laziness are antagonists to truly safe computing.

Paul

p2u
Valued Member
Valued Member

Posts : 211
Join date : 2010-12-14

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by ssj100 on 17/2/2011, 11:07

Rico, I've just been thinking. What exactly are you worried about? I mean, which "attack vector" are you concerned about? Remember that for an exploit (eg. Buffer overflow) to work, it must come in "contact" with your system first. So which form of contact are you worried about?

The thing I am personally most concerned about is how I handle newly introduced files that I want to potentially open and store away. For me, many of these newly introduced files are not always from "trusted and well known" sources. Happily, most of these files are discarded after viewing once or twice.

In terms of threat-gates (web browsers etc), I am much less worried about them. Even with just an Antivirus, the default XP firewall, and absolutely no tweaking, I never got infected (according to my Antivirus haha). I ran like this for years and (apparently) never had a problem. Why is this? Well, simply because I never downloaded and ran cracks willy nilly, and I never visited "high-risk" sites (among other things). I never clicked on pop-ups willy nilly and I never opened e-mails from "YOU ARE A WINNER OF A MILLION DOLLARS" company.

Now, I run in a LUA, enable a strict SRP, and tightly sandbox my threat-gates. And guess what, I still haven't got infected!

But in the end, the way I see it, if you only use your computer to view e-mails from trusted sources, post on forums like these, and not have anything written on your disk, never do any online transactions, and never store anything of significant personal value on your computer, why do you actually need all this "protection"? What exactly are you trying to protect? And wouldn't regular imaging be enough? Heck, I bet you don't "care" about your own body as much as your computer haha. So why put so much care into a piece of equipment that isn't doing that much for you? If you do play online games via plugins and open all attachments etc, as well as perform online transactions etc, then I can understand why you would want all this "protection". But to be honest, if you're not "riding a bike", why would you need to wear a "helmet". Right?

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Buffer Overflow Clarification

Post by p2u on 17/2/2011, 12:05

ssj100 wrote:I never visited "high-risk" sites
It would be good for the average layman to know what these are for 2011. I can't speak for the rest of the world, but for Russia I can say that nowadays you may be better off visiting p0rn sites than trying to look for a job online or trying to determine what that new mobile is going to cost you. Online video/audio is also a major source of infection. And how about social network sites and social engineering in general? And let's not forget advertising channels. Combined with all Default-Permit and Opt-Out schemes we are exposed to nowadays, this is more than enough reason to be vigilant. There's a good chance that if you go from ssj100.fullsubject[dot]com to wilderssecurity[dot]com and back, that you will not get infected, especially if you don't make more "friends" than is good for you. Very Happy

Paul

p2u
Valued Member
Valued Member

Posts : 211
Join date : 2010-12-14

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by Rico on 17/2/2011, 17:45

The attack vector I'm really concerned about is the browser. I know that using Chrome is a great way to cope with threats already, but I'm guess you can say that I'm paranoid about dealing with all kinds of threats that could come thru drivebys.

No I don't just use my computer for trusted sites. That would be pretty lame haha Smile Sometimes I dwelve into uncharted waters (not the kind you're thinking ) and thats why I'm thinking about this in the first place. What I'm aiming for is a robust setup that can withstand anything strictly coming from browsers as that is the only gate relevant to me. I also believe that opening any website without fear is a goal that I'm trying to achieve.
Protection of the computer's configuration from virus damage or harm is the main interest I have.

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by p2u on 17/2/2011, 20:06

Rico wrote:The attack vector I'm really concerned about is the browser.
I'm sure that if you use Sandboxie, you have nothing to be afraid of, especially if you are in a limited account and everything is backed up with SRP.
P.S.: If you would like to avoid exploits even within the sandbox, then you should realize that the real attack vector is plugins/addons the browser loads from the system, not the browser itself. The best strategy is to allow those only on sites that you trust. Most attacks also rely on java script. It would be best to have that disabled as well, or at least limited to trusted sites only.

Paul

p2u
Valued Member
Valued Member

Posts : 211
Join date : 2010-12-14

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by ssj100 on 17/2/2011, 23:21

Completely agree with p2u. I've personally achieved my goal of opening any web-site without fear. This process took about a year (2009) of heavy testing and "research". Essentially the idea is to harden windows as much as conveniently possible, and then combine it with a sandboxing setup/approach (maintaining security with convenience in mind). For me, sandboxing (with Sandboxie) provides the more "universal" protection.

With regards to protecting the computer's configuration from virus damage, the best "direct" protections have already been mentioned. The best "indirect" protection is of course regular imaging - I use Drive SnapShot - works brilliantly.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Buffer Overflow Clarification

Post by Rico on 19/2/2011, 18:47

I have learned to follow Rmus' advice, in that if a whole new emerging breed of exploits comes up, one would assess their own setup and make the necessary changes to deal with new threats. Its as simple as that. Who cares about the hundered of thousands of generic ways that driveby distributers comeup with every year? If one of them is a new kind of threat, then thats when I'll take a hard long look.
For me, mem-only virii seems like very unusual yet potentially powerful nasties. Once I found my way of dealing with them, its all good. The EMET from MS seems like a good one.

I know it sounds like I was freaking out, but actually I'm the type of person who likes to ask alot of questions to be able to understand as much as possible. Security is actually a very skilled game. Through it comes the freedom to use technology in any way we please.

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by p2u on 19/2/2011, 20:24

Rico wrote:I have learned to follow Rmus' advice, in that if a whole new emerging breed of exploits comes up, one would assess their own setup and make the necessary changes to deal with new threats.
Yes, such people are valuable. I've never seen him sell any FUD. His comments are realistic and to-the-point. Today he posted another of his demonstrations, this time Java being under attack:
http://www.wilderssecurity.com/showpost.php?p=1830591&postcount=10
Easily blocked with AE, of course. Also note the value of his "old" and "HIPS-less" Kerio firewall in the process.

Paul

p2u
Valued Member
Valued Member

Posts : 211
Join date : 2010-12-14

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by ssj100 on 20/2/2011, 00:56

Rico wrote:For me, mem-only virii seems like very unusual yet potentially powerful nasties. Once I found my way of dealing with them, its all good. The EMET from MS seems like a good one.
You are not happy/convinced enough that Sandboxie is able to contain such memory-only virii? I was impressed that Didier's POC was able to "bypass" SRP/AppLocker, Faronics Anti-Executable and all HIPS out there, but since it didn't bypass Sandboxie, I wasn't worried. The fact is that there will always be something we're overlooking - this is the reason why I like to use two separate sandboxed web browsers (configured appropriately). No matter how you look at it, if you're a "higher risk user" and you have something sensitive to "protect" (and you have Sandboxie installed), applying this approach of using two separate sandboxed web browsers will always be more secure than not applying it.

It may sound like I am heavily relying on Sandboxie, but I don't see a problem with that - it's proven to be very robust against POC's and against real-world malware. And I have first-hand experience of that.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Buffer Overflow Clarification

Post by Rico on 20/2/2011, 02:19

On the contrary, Sandboxie is the cornerstone of my security approach. But my approach is one of having multiple lines of defense just incase of any (hypothetical) failure of one barrier. Sandboxie on a 32bit is rock solid, therefore such measures are unnecessary. I was considering a very unlikely scenario where a memory only payload, on a 64bit system could have loaded and potentially executed a malicious DLL purely in memory. Where this could communicate with a service and attempt breakout. --Very small chance but possible.

Having a read-only sandbox basically eliminates the chance of all downloaded to disk malware, from existing. Leaving memory as the remaining potential vector.

You may argue "But who cares, why is any of this necessary?Shocked"
I'll tell you why:
Seeing that a tool with Meterpreter's abilities included in a public exploit kit available to any snot nosed scriptkiddie is quite a big deal. I bet real cybercriminals have already come up with new ways like these to hose systems. Threats are evolving very quickly, thats why you need to stay ahead of the wave. The reason we don't hear about mem-only is that they are stealthy in nature and because most people on the interenet are not educated enough about threats to be able to spot them.

One thing I hate about Microsoft and the security industry's forced obsolecence of software. Their policy of publishing full-disclosure puts everyone at risk and lets hell break loose for systems. This gives 0day developers an opportunity to be a step ahead as they have everything to work with out there. There are many patched exploits that are being exploited for their 3rd and 4th times!

As I said before, its a game where the highly skilled win.

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by ssj100 on 20/2/2011, 02:56

Rico wrote:I was considering a very unlikely scenario where a memory only payload, on a 64bit system could have loaded and potentially executed a malicious DLL purely in memory.
I didn't realise you were personally running a 64-bit system. It all makes sense now haha.

Slightly off topic, but since I don't play (modern) PC games that would take full advantage of a 64-bit processor, and I don't even come close to utilising more than 2Gb of RAM at any one point, I am still happily running a 32-bit machine. If you're really that concerned about the apparent "holes" of a 64-bit system, perhaps you could consider installing a 32-bit Windows system instead? For those yelling "think about the future!" and "you might as well get used to a 64-bit system now!", well, tell that to me when "Windows 8" is released and I'll re-consider my stance.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Buffer Overflow Clarification

Post by p2u on 20/2/2011, 11:20

Rico wrote:One thing I hate about Microsoft and the security industry's forced obsolescence of software. Their policy of publishing full-disclosure puts everyone at risk and lets hell break loose for systems. This gives 0day developers an opportunity to be a step ahead as they have everything to work with out there. There are many patched exploits that are being exploited for their 3rd and 4th times!

As I said before, its a game where the highly skilled win.
Can't agree with you.
1) Full disclosure is good as long as it is responsible disclosure. You can't protect yourself from threats you aren't aware of. At the same time, assuming that hackers don't know what isn't disclosed fully would be naive. The only difficult thing for the poor customer (psychologically) is coping with the hype AV vendors, self-proclaimed security "experts" and the mass media make out of it; "nothing personal; just business".
2) Blocking attack vectors is actually VERY simple and VERY easy and does not depend in any way on the snake-oil "solutions" that are offered. Besides, however clever the implementation of nasties as soon as they are launched, preventing them from launching, preventing them from hitting you really hard has always been the same. The only factor I make a point of underlining is the role "TRUSTED" applications (not what you trust, but what MS & Friends trust) play in the game. SHUT THEM OFF IF YOU DON'T NEED THEM. Replace, remove stuff that is often attacked (Java, Flash, Adobe PDF, QuickTime, RealPlayer, etc). If you need personal help in determining redundant stuff, just ask.

P.S.: Unfortunately, lying, bending the truth a little or concealing info to keep customers from making educated decisions, from forming sound opinions is an art. For example, I get very, very angry when I see this kind of statistics: Top Most Vulnerable Applications and Operating Systems in 2010 and I even fall off my chair when I see that people who are supposed to know better draw conclusions like:
152 vulnerabilities were found in Program X, 54 in Program Y. Therefore, program Y is safer.

Instead they should have added
1) how many of those vulnerabilities were actually exploitable and under what circumstances?
and
2) how many of those vulnerabilities are actively being attacked?
3) how fast did they close the holes?, etc.

The fact that we don't get this essential info causes all the confusion, Fear, Uncertainty and Doubt. F*** 'em all, Rico, especially marketing people and advertisers. It's time for you to determine yourself what should be on your system, what not, and how to protect your system based on reliable info from true and independent professionals that have nothing to sell. That's the key to true security. The rest is bull. It's high time computer users' rights got protected by an ombudsman and those that systematically try to mislead them got punished...

Paul

p2u
Valued Member
Valued Member

Posts : 211
Join date : 2010-12-14

View user profile

Back to top Go down

Can Buffer overflow bypass LUA?

Post by sanbox man on 19/8/2016, 15:16

ssj100 wrote:
Now, I run in a LUA, enable a strict SRP, and tightly sandbox my threat-gates. And guess what, I still haven't got infected!
Can Buffer overflow bypass LUA? If so how does it do it under LUA restrictions?

sanbox man
Member
Member

Posts : 10
Join date : 2016-08-17

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by ssj100 on 19/8/2016, 15:59

Probably best to research what LUA is.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

I have read LUA before I posted

Post by sanbox man on 19/8/2016, 18:34

ssj100 wrote:Probably best to research what LUA is.
Actually I read long article at Technet about LUA before I commented.

sanbox man
Member
Member

Posts : 10
Join date : 2016-08-17

View user profile

Back to top Go down

Re: Buffer Overflow Clarification

Post by Sponsored content


Sponsored content


Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum