Buffer Overflow Attacks and Their Countermeasures

What is buffer overflow, why is it dangerous and how is it preventable?
Overwriting Function's Return Addresses

Because we know it is easy to overwrite a function's return address, an intelligent hacker might want to spawn a shell (with root permissions) by jumping the execution path to such code. But, what if there is no such code in the program to be exploited? The answer is to place the code we are trying to execute in the buffer's overflowing area. We then overwrite the return address so it points back to the buffer and executes the intended code. Such code can be inserted into the program using environment variables or program input parameters. An example code that spawns a root shell can be found in a classic paper written by Aleph One for Phrack Magazine (see Resources).

Buffer Overflow Countermeasures

The solutions proposed for buffer overflow problems mainly target the prevention of large-scale system attacks through the loopholes described above. None of the methods described below can claim to prevent all possible attacks. These methods, however, can make it more difficult to access buffer overflows and, hence, destroy the consistency of stacks.

  1. Write secure code: Buffer overflows are the result of stuffing more code into a buffer than it is meant to hold. C library functions such as strcpy (), strcat (), sprintf () and vsprintf () operate on null terminated strings and perform no bounds checking. gets () is another function that reads user input (into a buffer) from stdin until a terminating newline or EOF is found. The scanf () family of functions also may result in buffer overflows. Hence, the best way to deal with buffer overflow problems is to not allow them to occur in the first place. Developers should be educated about how to minimize the use of these vulnerable functions.

  2. Stack execute invalidation: Because malicious code (for example, assembly instructions to spawn a root shell) is an input argument to the program, it resides in the stack and not in the code segment. Therefore, the simplest solution is to invalidate the stack to execute any instructions. Any code that attempts to execute any other code residing in the stack will cause a segmentation violation. However, the solution is not easy to implement. Although possible in Linux, some compilers (including GCC) use trampoline functions (see Resources) to implement taking the address of a nested function that works on the system stack being executable. A trampoline is a small piece of code created at run-time when the address of a nested function is taken. It normally resides in the stack, in the stack frame of the containing function and thus requires the stack to be executable. However, a version of the Linux kernel that enforces the non executable stack is freely available (see Resources).

  3. Compiler tools: Over the years, compilers have become more and more aggressive in optimizations and the checks they perform. Various compiler tools already offer warnings on the use of unsafe constructs such as gets (), strcpy () and the like. For example, this code

    int main () {
        char *str = (char *)malloc(10);// allocate 10 bytes for str
        gets (str); // reads input from stdin and store into str
    }
    
    when compiled with GCC, returns the following warning:
    /tmp/cc203ViF.o: In function "main":
    /tmp/cc203ViF.o(.text+0x1f): the "gets" function is dangerous and should
    not be used.
    

    Apart from offering warnings, modern compiler tools change the way a program is compiled, allowing bounds checking to go into compiled code automatically, without changing the source code. These compilers generate the code with built-in safeguards that try to prevent the use of illegal addresses. Any code that tries to access an illegal address is not allowed to execute.

    These kind of tools, however, require the source code to be recompiled with a newer compiler. This requirement may be a problem if the application is not open source. Furthermore, it may affect the application's performance to a great extent. In some case, executable size and execution time may increase two-fold.

    A patch for GCC that does bounds checking can be found here. Recently, however, most of the tools have concentrated on preventing the return address from being overwritten, as most attacks occur this way. StackShield is a freely available tool that copies the return address of a function to a safe place (usually to the start of the data segment) at the start of the function. When the function terminates, it compares the two function return address, the one in the stack and the one stored in data segment. In the case of a mismatch, the function aborts immediately.

    Because a function also can call another function, it needs to maintain a stack kind of structure for storing return addresses. Another tool available is StackGuard, which detects and defeats smash stacking attacks by protecting the return address on the stack from being altered. It places a canary word next to the return address whenever a function is called. If the canary word has been altered when the function returns, then some attempt has been made on the overflow buffers. It responds by emitting an alert and halting.

  4. Dynamic run-time checks: In this scheme, an application has restricted access in order to prevent attacks. This method primarily relies on the safety code being preloaded before an application is executed. This preloaded component can either provide safer versions of the standard unsafe functions, or it can ensure that return addresses are not overwritten. One example of such a tool is libsafe. The libsafe library provides a way to secure calls to these functions, even if the function is not available. It makes use of the fact that stack frames are linked together by frame pointers. When a buffer is passed as an argument to any of the unsafe functions, libsafe follows the frame pointers to the correct stack frame. It then checks the distance to the nearest return address, and when the function executes, it makes sure that address is not overwritten.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

need for diagrams

bashu's picture

thi site is very gud. but we need some diagrams for well known about buffer. thank you

Remote launching of buffer overflows

remotebuffer's picture

Hi sandeep,
Thanks a lot for the fantastic effort. I was wondering how a hacker can launch the buffer overflow atack remotely.
It was quite clear from your article how the buffer overfloe happens on a local system. In fact I was reading the following pdf ""A Bu®er Over°ow Study
Attacks & Defenses
Pierre-Alain FAYOLLE, Vincent GLAUME
ENSEIRB
Networks and Distributed Systems
2002"
which talks about the same and mostly shows ways and tools to protect against buffer overflow attacks.
But I wan to know how the attack is actually launched.
Say a user is sitting on a machine A and a hacker is sitting on machine B. They are in different cities. In such a case how will the hacker make its malicious code run on the user's machine, i mean to say how will a hacker sitting in a different geographical location overflow the memory buffer on the user's local system over the network/internet...
it seems that the last response on your article was more than 40 weeks ago... so if you reply I would be very grateful.

Using string libraries to mitigate buffer overflows

Paul Hsieh's picture

> Write secure code: Buffer overflows are the result
> of stuffing more code into a buffer than it is meant
> to hold. C library functions such as strcpy (),
> strcat (), sprintf () and vsprintf () operate on null
> terminated strings and perform no bounds checking.
> gets () is another function that reads user input
> (into a buffer) from stdin until a terminating
> newline or EOF is found. The scanf () family of
> functions also may result in buffer overflows. Hence,
> the best way to deal with buffer overflow problems is
> to not allow them to occur in the first place.
> Developers should be educated about how to minimize
> the use of these vulnerable functions.

Ok, but one clear way to avoid problems with these functions is to absolutely ban their use in the first place. That may seem heavy handed or impractical, but its not if you have an alternative that is ready to use to substitue for the functionality of all those functions. That is to say you simply need a comprehensive string library that performs automatic buffer management and delivers sufficient functionality and simply switch to it.

I think the two main alternatives that I would recommend for C programmers is either James Antil's "Vstr":

http://www.and.org/vstr/

or my own library, "The Better String Library":

http://bstring.sf.net/

They attack the problem with different philosophical mindsets (as James says, his is a buffer manager for struct iovect *, while mine is a buffer manager for char *), but either one is sufficient significantly reduce the occurrence of buffer overflows, while delivering all sorts of side features which you can read about at their respective home pages.

For C++, you can also use my library, however either STL's std::string or Microsoft's MFC based CString class are also good alternatives for automatically buffer managed strings.

The problem with using functions like snprintf/strncat/strlcpy, etc, is that they don't remove the problem of buffer overflow, they simply change them. Remember that buffer overflows, fundamentally come program programmer errors. Just because you've reformulated that problem doesn't mean programmers are going to stop making errors. The advantage of a dynamic string library is that the problem of buffer management for strings (and/or other kinds of memory buffers) is completely solved for you. So these kinds of buffer overflow errors basically cannot happen.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Purdue University has a nice website about buffer overflow attacks and prevention methods including their hardware based approach called SmashGuard. Check out www.smashguard.org

Spot the difference

Anonymous's picture

Half of this article has just been ripped and paraphrased from Aleph1's original. It would have been easier just to paste the url to Phrack, or create a .diff for 'Smashing the stack for fun and profit'. Apart from that, it's good

"The standard C library provides a number of functions for copying or appending strings, that perform no boundary checking. They include: strcat(), strcpy(), sprintf(), and vsprintf(). These functions operate on null-terminated strings, and do not check for overflow of the receiving string. gets() is a function that reads a line from stdin into a buffer until either a terminating newline or EOF. It performs no checks for buffer overflows. The scanf() family of functions can also be a problem"


"C library functions such as strcpy (), strcat (), sprintf () and vsprintf () operate on null terminated strings and perform no bounds checking. gets () is another function that reads user input (into a buffer) from stdin until a terminating newline or EOF is found. The scanf () family of functions also may result in buffer overflows"

Read

Anonymous's picture

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

very good articles...
but there is a thing that leave me very surprised: why we can execute instructions in the data segment?? since now i have believed the memory paging system marks the memory pages with 3 bits: r,w,x ... so if program counter points to something in a data page (r or r,w) a page fault should occour... where's the trick???

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

I was thinking the same thing. The author says that gcc places "trampoline code" in the stack (segment) making it executable "(in order) to implement taking the address of a nested function that works on the system stack being executable." huh? That would be a big mistake. Makes me wonder if Linux is any better than Windows.
Local C functions are non-standard --I know gcc allows them and I've used them, very nice-- but they are still "static". Only their names are hidden inside the enclosing function.
You don't need any code in the stack to follow C++ exception handling, so what are you talking about Sandeep????

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

>No tool can solve completely the problem of buffer overflow

Huh? You seem to be saying that keeping track of the size of the destination buffer doesn't work. Barring an error at the hardware level (or incorrect function implementation), how can a properly used *sn* function lead to an overflow?

Failure to use a tool properly does not make the tool faulty.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Making strcpy() safe is easy, but it's use is slightly different. Here's my own source code to a safer strcpy:

#include // for printf()
#include // for memset()

char *sstrcpy(char *dest, const char *src);

int main(int argc, char *argv[])
{
char buffer[20];
memset(&buffer,1,19) //set buffer -1 with 1's
sstrcpy(buffer,argv[1]);
printf("buffer is : %s (%d)
",buffer,strlen(buffer));
return 0;
}

char * sstrcpy(char *dest, const char *src)
{
char *temp = dest;
while (*dest != '') {
if (*src == '')
{
*dest++ = '';
return temp;
}
*dest++ = *src++;
}
*dest++ = '';
return temp;
}

Let me know what you think.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

// these are not valid C comments, and will not be recognized by a C compiler such as gcc, but are recognized by a C++ compiler such as g++

/* these are valid C comments */

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Oops, forgot a bit of code:

between memset() and sstrcpy()
add
buffer[20] = '';

That should make it work fine.

Example output:

$ ./test AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
buffer is : AAAAAAAAAAAAAAAAAAAA (20)

$

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Try adding the line below (defining badthing) and then see what happens when you pass 20 chars. You end up with a non-terminated string, which when printed, appends the string immediately following in memory. Woops.

char badthing[20]="what the hell happened...";
char buffer[20];
memset(&buffer,1,19) //set buffer -1 with 1's
sstrcpy(buffer,argv[1]);

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

but it's a deliberate overflow by the code author, not the user

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

I would just like to thank Linux Journal for updating the article to correct errors mentioned in the discussion. This is especially interesting, as they didn't feel justified to mention that they updated the article. Thank you for the shining exampling of journalism you present to the world.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Wonderful article and context !

I feel I am sitting in a newsgroup !

More articles like this please. I think this can be a good forum for

people to discuss technical ideas.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

You forgot to mention runtime-checking tools like valgrind and purify.

Other than that, looks pretty unprofessional

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Did u mean professional??? Since I thought the other way round....

What about LIDS?

Anonymous's picture

Buffer overflows would not be nearly the security nightmare they are if the root account were not all-powerful and if network and system daemons like apache were not run from the root account. Fixing this turns out to be simpler than you might think with the LIDS kernel patch.

LIDS stands for Linux Intrusion Detection System. I think of it as a firewall that sits between a process and the kernel when system calls are made. With it, priviledges can be granted to and taken away from individual programs (based on the inode of the executable program file) instead of to user accounts.

If the only root priviledge the apache program possesed was the ability to bind to port 80, and someone found a buffer overflow in apache and exploited it, and they managed to get a remote root shell from it, it would buy them little if the normal powers of the root account had been stripped away.

See www.lids.org for more information.

Although you have to spend some time configuring the permissions table for the applications you want to run, it is quite manageable and only has to be done once. I think this is the ultimate answer to bufferflows: make it so that even when a buffer overflow is found, the attacker can't do anything with it.

Chris Marshall

Re: Buffer Overflow Attacks and Their Countermeasures

bl0wfi5h's picture

Well one solution to this problem could be the new Openbsd 3.2 kernel policy, that most of the stack programming is removed. You can also config systrace and config it but it takes alot of time if you want it to work good.

Those are my best answers to how sysadmins could protect themselfs against Buffer overflow attack. And also one more thing, PROGRAMMERS DONT write shitty code!!! buffer overflow is really easy to avoid, in the programming state.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Well presented Article!!

Re: Buffer Overflow Attacks and Their Countermeasures

bl0wfi5h's picture

well one solution to this problem could be the new Openbsd 3.2 kernel policy, that most of the stack programming is removed. You can also config systrace and config it but it takes alot of time.

Those are my best answers to how sysadmins could protect themselfs against Buffer overflow attack. And also one more thing, PROGRAMMERS DONT write shitty code!!! buffer overflow is really easy to avoid, in the programming state.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Consider some very simple program whose main() calls a function, passing it a couple of parameters. Then compile with the -S switch (upper case) e.g.

gcc -S simple.c

producing simple.s. This file then shows the assembly language translation with the explicit stack behavior revealed.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

well one solution to this problem could be like the new Openbsd 3.2 kernel, that most of the stack programming is removed. You can also config systrace and config it.

Those are my best answers two how sysadmins should protect against Buffer overflow attack. end also one point. PROGRAMMERS DONT write shitty code!!! buffer overflow is really easy to avoid, in the programming state.

/mr.J

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

>No tool can solve completely the problem of buffer overflow

Probably true, if C is the only language you know.

Seriously, the choice of language for implementing any

system should consider the tradeoffs involved, and the

risk (and expense of finding and fixing) buffer-overflow

problems is one of the BIG tradeoffs. The article would

be stronger if it started with a mention of this issue.

There are places where a low-level language such as C

must be used, but far too often a high-level language

would be the choice of a responsible engineer.

"Performance" is seldom important enough to require

accepting the risks of low-level errors such as buffer

overflows (or wild pointers, or any of the C "Traps

and Pitfalls"). Yes, there's even a book, a very good

book by that title.

Bill Sconce

In Spec, Inc.

New Hampshire

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Performance is seldom important enough to require
accepting the risks of low-level errors such as buffer
overflows

Yes it is, in almost every application.
I despise the attitude that performance doesn't matter because memory and cpu is cheap, well it ain't cheap enough to warrant that attitude, which leads to software getting evermore bloated.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

No tool can solve completely the problem of buffer overflow

Probably true, if C is the only language you know.

Amen, brother!

COBOL, Ada, Pascal, BASIC & Python pop instantly into my head as languages where such bugs will never occur.
Programmers that have such a bias towards C should get a real clue. It is a poor tool for many problems.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

"COBOL, Ada, Pascal, BASIC & Python pop instantly into my head as languages where such bugs will never occur. Programmers that have such a bias towards C should get a real clue"

This is FUD. It is biased and untrue.

Pascal and BASIC got the same problems. I don't know if COBOL and Python do, so I refrain from arguing on this issue.

Ada, C# and Java are usually compiled into managed environments which solve the problem. Naturally, at the expense of complete bound checking at every buffer access (which I agree on is often acceptable).

It is not REALLY an issue on the side of the language as the poster seem to believe, it is an issue of
- is code running "live" or "managed" ?
- if not managed, are every API and possible way to express yourself within the language bound checked?

I do not give much for the argument of Pascal syntax making code better than C. It's an old and biased argument which I do not believe is based on good statistics.

Of course, Pascal programmers code C badly. But what of experienced C programmers vs experienced Pascal programmers in their native language? Do Pascal programmer really produce better code? I doubt it.

Bad statistics are based on bad comparisions like what unexperienced programmers yield in different langauges. Additionally, since most code is written in C, it is also a _lot_ of inexperienced programmers coding in C.

Pascal has _never_ been mainstreamed enough to been tested with the "30% of the programmers cannot code, what do they produce" test C is experiencing every day. Pascal, Ada, Fortran etc programmers tend to be better educated because they are mostly used by researchers or people will univerisity or college experience.

//P

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

I have been out of touch with technology since the last 4years but still could understand the article extremely well.

Very good read.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

>No tool can solve completely the problem of buffer overflow

IBM iSeries AS/400 has firmware/hardware based protection against buffer overflow and several other potential vulnerabilities.

Problems currently plaguing the PC world have long been solved or never existed in the kingdom of large iron.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

As does most SUN's. You have to enable it though.... You'd think that something like that that is implented in hardware should be on by default if only to catch buggy software.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Nice, easy to understand article, but for the strncpy blunder !!

Dont mind, keep it up !!

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Sandeep, nice article; I'd like to offer the following papers for further reading for interested readers:

http://wirex.com/~crispin/opensource_security_survey.pdf
(published in IEEE's new Security & Privacy Magazine)

"Buffer Overflows: Attacks and Defenses for the Vulnerability of
the Decade". Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie, and
Jonathan Walpole. DARPA
Information Survivability Conference and Expo (DISCEX)
, Hilton Head
Island SC, January 2000. Also presented as an invited talk at SANS 2000, Orlando FL,
March 2000. PDF.

Seth Arnold, WireX Communications

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

for more relevant projects unfortunately left out from Dr. Cowan's aforementioned article the interested readers are invited to check out the following sites as well:

http://www.rsbac.org/

http://www.grsecurity.net/

http://pageexec.virtualave.net/

also a better implemented gcc stack overflow detection patch is at:

http://www.trl.ibm.com/projects/security/ssp

cheers, the PaX Team

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

I have been trying to cite PAX, especially the ASLR work, but good references are hard to come by. http://pageexec.virtualave.net/ is just a home page with source code. Please provide canonical references to technical documentation, and PAX will be better cited in the future.

Thanks,

Crispin

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Oops; http://pageexec.virtualave.net/ does have documentation. IIRC, it was not there when I wrote the IEEE survey last fall.

Crispin

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

indeed, the PaX docs were released about a month ago (and one of them is still pending). on the other hand, both RSBAC and grsecurity had extensive documentation available already.

cheers, PaX Team

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

---BEGIN QUOTE---

void function (char *str) {

char buffer[16];

strcpy (buffer, str);

}

int main () {

char *str = "I am greater than 16 bytes"; // length of str = 27 bytes

function (str);

}

... Using strncpy would have caught the problem and set off a compile-time error.

---END QUOTE---

Um, no. Why don't you try that for yourself and see how wrong you are. Seriously. That's embarrassingly bad. And it makes me wonder how useful the rest of the coding tips in the article are.

You want to write function() as follows:

void function( char *str )

{

char buffer[16];

strncpy( buffer, str, sizeof(buffer) - 1 );

buffer[sizeof(buffer) - 1] = 0;

}

This will copy bytes from str to buffer, and still maintain a properly NULL-terminated string. If you're just moving raw bytes around, you can drop the -1 from the length and remove the last line of the function.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

You know, it seems to me that this argument posed above is incorrect, as the following code does in fact compile.. What was the argument? That it was insecure? If so, this is true, but the author of this article was expressing that fact, and that is the whole reason it was written, to demonstrate what an overflow was. Please note I don't concider myself as a genius knowing this...

#include

void function (char *str) {
char buffer[16];

strcpy (buffer, str);
}

int main () {
char *str = "I am greater than 16 bytes"; // length of str = 27 bytes

function (str);
}

====================================
Type it, compile it, re-read the article.

strlcpy()

Anonymous's picture

The solution is to use strlcpy() instead of strncpy() ....

http://www.courtesan.com/todd/papers/strlcpy.html

On the attitude:

Being nasty online to our fellow Linux pals isn't nice.

It was clear what the original author was trying to say at it was

essentially correct.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

If we're going to nitpick, let's do it correctly:

  • If all you're doing is moving raw bytes round, you should be using
    memcpy(), not strncpy().
  • Just silently truncating the passed buffer is almost always incorrect. You
    check before you copy: if the source string is too long, it's either a programming error, in which case there should be an assert(), or the
    user needs to be notified that she exceeded hard-coded limits (or the
    code needs to be fixed so that it doesn't have a hard-coded limit.

Just to be fair, I'll nitpick on the original article too: The very first
example is described as being "valid code". Wrong. It's invalid, and
explicitly so by the ISO C standard. That it compiles dosn't make it "valid".
But overall, a good overview of how buffer overflow exploitation works.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

Just silently truncating the passed buffer is almost always incorrect. You check before you copy: if the source string is too long, it's either a programming error, in which case there should be an assert(), or the user needs to be notified that she exceeded hard-coded limits (or the code needs to be fixed so that it doesn't have a hard-coded limit.

I assume you mean he should check the length with strlen(). But strlen() has unbounded execution time, and if the string does not contain the character at all, strlen() will (potentially) run forever! It can have fatal consequences for a program with real-time requirements. In this situation it is much better to just safe-guard truncate the buffer.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

For whoever wrote this comment,

I agree with the correction, but no need for the bad attitude. Maybe strncopy would not have set off a compile time error, but it is in your solution isn't it?

anonymous

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

I agree with the first poster. And the attitude is well deserved. If you're going to talk about secure programming, but get something obviously wrong like that, you deserve to get ripped.

Note that in the correction strncpy() is used, but it takes into consideration the size of the buffer that's being copied into. There is still a bug in it though, in that there isn't support for input strings that are shorter than 15 bytes in length.

Re: Buffer Overflow Attacks and Their Countermeasures

Anonymous's picture

>There is still a bug in it though, in that there isn't support for input strings that are shorter than 15 bytes in length.

Err, strncpy copies *at most* n bytes; it still terminates on null byte.

Hi Had a question, is it p

Rajiv's picture

Hi

Had a question, is it possible for a hacker to launch buffer overflow attack without having access to source code ?

-Rajiv

Hi rajiv it is possible, wit

Anonymous's picture

Hi rajiv it is possible,
with out knowing source code also we can do buffer overflow attacks. Buffer overflow attaks are possible in windows environment also.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState