I'm currently following a course on secure programming. Since it's targeted mainly at C/C++/Java programmers, I have a lot of unanswered questions regarding Perl programming.
The most important one I have is related to buffer overflows. My understanding of this kind of exploit is that the runtime memory is accessed in an abnormal way in order to get to sensitive data and/or run arbitrary code. Which brings up the Garbage Collector.
From previous posts, I learned that, for exemple, using undef on data structures releases the memory back to the Perl interpreter for reuse. The same thing happens when a reference goes out of scope. What I would like to know is what reallly happens to the bits when the memory is released. Are the all reset to 0? Are they left as is (thus possibly creating an opening following a buffer overflow)? Finally, is memory management the same with scripts converted to executables by perlapp or perl2exe?
Regards,
Solostian
-- "Fortunately, ridicule does not kill..."
I can't say "Perl doesn't have a buffer overflow problem" because there are probably some sneaky ways that no-one's figured out an exploit for (yet).
As to questions I can answer: The perl allocator (as well as most system allocators) does nothing with memory after it's released except reset arena pointers if necessary. Some allocation routines (depending on version and such) will guarantee to initialize memory to 0, but I don't know of any outside of specialized applications that will clear memory contents prior to releasing it.
Both perlapp and perl2exe use whatever underlying perl system they packaged the program with, so they inherit all of the basic memory management, thread management, etc., capabilities and features -- both good and bad.
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?
Whether or not garbage-collected data is zeroed out after collection doesn't affect buffer overflows one way or the other. It could possibly affect information leakage, but the Perl language always initializes variables to something (even if it's undef), so they never end up pointing to uninitialized memory.
Because of its design, the Perl language is immune to these attacks and to buffer overflow attacks. However, a bug in the Perl interpreter could lead to a buffer overflow; this is the same as with Java, or any other interpreted language (compiled languages have the same problem with potential bugs in their compilers). This would of course be a flawed implementation, but looking at any recent ChangeLog for the Perl interpreter will confirm that every implementation so far has been flawed in some way, and it's likely future ones will have flaws from time to time.
That said, I've found Perl to be the easiest language to write secure programs in, because of the language design and because of taint mode. So far none of Perl's bugs have created real security problems in my applications, so I've been happy from that perspective as well. Perl's developers take security very seriously, and I have confidence that the remaining bugs will be small ones and quickly fixed when they are discovered.
Because of its design, the Perl language is immune to these attacks and to buffer overflow attacks. However, a bug in the Perl interpreter could lead to a buffer overflow;
This is not exactly true. Think of a perl extension, which is written in C or C++ or any other language which suffers from those "traditional" buffer-overflow problems. Those could bring the problem of buffer overflow attacks to your perl application, even if perl is theoretically immune to such attacks.
This is why I usually prefer pure-perl implementations when I choose to use a module from CPAN. At least as long as performance doesn't suffer too much.
Cheers, Flo