How do you know that buffer overflow has been carried out.

B

bryn1u

Hey guys,

Im reading and trying to find how to log that exploit attack or buffer overflow has been carried out ?
Many of things that user does, have been logged but what about exploit attacks or buffer overflow attacks ? Is there any way to check it or log it ?
I mean users who have access to shell access.
I was looking for similar topic on forum but found nothing related to.

Regards,
 
Your question is so general, it is impossible to answer. There are lots of companies that make big money by doing "intrusion detection", which is exactly what you are asking for.

"Many of things that user does, have been logged ...". No, wrong. Nearly all actions that a user does from a command line are NOT logged. Typically, for a normal user session, the only things that are logged is when the user logs in and logs out. If they use su or sudo, the fact that they did that (typically to become root) is also logged, but not the details of what they did while they were root.
 
Hard to tell. Typically, a buffer overflow is going to execute additional code (that which was injected) so could be in the form of a remote code execution (RCE). I am a penetration tester but buffer overflows are not my speciality.
 
ralphbsz said:
Your question is so general, it is impossible to answer. There are lots of companies that make big money by doing "intrusion detection", which is exactly what you are asking for.

"Many of things that user does, have been logged ...". No, wrong. Nearly all actions that a user does from a command line are NOT logged. Typically, for a normal user session, the only things that are logged is when the user logs in and logs out. If they use su or sudo, the fact that they did that (typically to become root) is also logged, but not the details of what they did while they were root.
Click to expand...
What about kernel ? what u say. Really is that kernel save nothing ? Any bits or something ? Soo u want to say to me, some guy runs an expolit and knows know about ? is it misconception for you ?
 
Sevendogsbsd said:
Hard to tell. Typically, a buffer overflow is going to execute additional code (that which was injected) so could be in the form of a remote code execution (RCE). I am a penetration tester but buffer overflows are not my speciality.
Click to expand...
"injected" almost crash becuause memmory addre has not been found.
 
Injected in this case means exploiting a buffer overflow and injecting malicious executable code into the memory area that was "overflowed".
 
As a yet another futile attempt to be nice I'll try to give you an explanation. Any 100% reliable method of detecting buffer overflows (for programs written in a language without bounds checking, such C) would be an instant hit and implemented pretty much everywhere as a part of regular exploit mitigation measures, making this whole question a non-issue.
 
Yes, even with diligent removal of obvious buffer overflow candidates like gets, one can't mitigate cache sharing across CPUs (internal or external) and so on (looking at you Intel).

To help the OP in his/her search for overflow exploitation:

I would guess most buffer overflows happen in userland anyway (much lazier code) and then the worst that can happen is probably a segfault. So, write a program that executes a buffer overflow and see what you can find. Then move on to the kernel.
 
bryn1u said:
What about kernel ? what u say. Really is that kernel save nothing ? Any bits or something ? Soo u want to say to me, some guy runs an expolit and knows know about ? is it misconception for you ?
Click to expand...
The kernel doesn't log 99.999% of what it does. If it did, the logs would be enormous. Matter-of-fact, I've run systems (for debugging or performance measurement) with full kernel tracing enabled, and the logs require adding several extra disk drives just to write them.

You also need to think about what the real attack is. Some guy logs into your computer, and runs a piece of code that uses an exploit. If the guy is a normal (unprivileged) user, and he is still an unprivileged user afterwards, exactly nothing has happened. So they only exploits that are interesting are privilege escalation: He either finds a secret that he shouldn't have been able to see (for example the ssh key for the root account), or he is able to become root. In the first case, the next thing you will see that root logs in or starts a process in some fashion, and that is usually not logged or only barely logged. Look in your login logs. In the second case, you now have a process that has root privileges, and does some operation. How do you expect to see that in the logs?

I think you need to explain more clearly what you want.
 
Raffeale said:
I also want to ask a question, when I open secure level to 2, the EIP in stack memory can be change by some exploit code?
Click to expand...
The security level has nothing to do with buffer overflows (or their prevention).

Code: 
     The kernel runs with five different security levels.  Any super-user
     process can raise the level, but no process can lower it.  The security
     levels are:

     -1    Permanently insecure mode - always run the system in insecure mode.
           This is the default initial value.

     0     Insecure mode - immutable and append-only flags may be turned off.
           All devices may be read or written subject to their permissions.

     1     Secure mode - the system immutable and system append-only flags may
           not be turned off; disks for mounted file systems, /dev/mem and
           /dev/kmem may not be opened for writing; /dev/io (if your platform
           has it) may not be opened at all; kernel modules (see kld(4)) may
           not be loaded or unloaded.  The kernel debugger may not be entered
           using the debug.kdb.enter sysctl.  A panic or trap cannot be forced
           using the debug.kdb.panic and other sysctl's.

     2     Highly secure mode - same as secure mode, plus disks may not be
           opened for writing (except by mount(2)) whether mounted or not.
           This level precludes tampering with file systems by unmounting
           them, but also inhibits running newfs(8) while the system is multi-
           user.

           In addition, kernel time changes are restricted to less than or
           equal to one second.  Attempts to change the time by more than this
           will log the message "Time adjustment clamped to +1 second".

     3     Network secure mode - same as highly secure mode, plus IP packet
           filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be
           changed and dummynet(4) or pf(4) configuration cannot be adjusted.

     The security level can be configured with variables documented in
     rc.conf(5).
See security(7).
 
You must log in or register to reply here.
Back
Top