1. Attacker locates buggy code that harbors buffer overflow opportunity
2. Attacker crafts input that overflows buffer, placing custom code into location in memory that is executable and further crafts input so that that custom code is jumped to and executed.
3. The custom code is typically code that gives the attacker a root shell or some such.
In other words, the nature of the attack is predicated on the ability of C/C++ code to address memory directly. This is key. In Perl, we don't have the ability to address memory directly, thus rendering buffer overflows an improbability (throwing away the potential for exploits of interpreter bugs).
Attacking Perl code is different. Since Perl doesn't address memory, you can't overflow a buffer and write root-shell-launchers to stack/heap areas. Rather, you must take a different approach. The goal is the same - a root-shell-launcher. So...
1. Find a Perl daemon running as root or some other privileged user id that you'd like to mess about with
2. Craft input to the Perl deamon that takes advantage of bugs in the code to launch a root-shell launcher
No buffers to overflow? No problem...
1. back-ticks
2. system()
3. /e enabled regexes
4. piped open() calls
etc.
In other words, use the same approach as in attacking C/C++ - find privileged code that doesn't sufficiently validate input and take advantage of that to craft custom inputs to the code that will launch a root shell.
This is why we use taint mode in all CGI programming. Remember - all insecure code is that way because it makes assumptions that are not always true. Validate your input in all cases and security problems vanish. Easily stated, much less easily done. Good luck.
,welchavw - can't always be bothered to login, now can I?
In reply to Re: Garbage Collection & Secure Programming
by Anonymous Monk
in thread Garbage Collection & Secure Programming
by Solostian
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |