You wouldn't directly. You'd allocate a buffer from the heap, then push a pointer to it on the stack.
What scenarios are these?
The big one is return into libc. Since the C library contains valid functions that are already marked as code, all you have to do is find one that does what you like, e.g. something from the exec family. As you're overflowing, you overwrite not just the return address, but the memory after it, creating a fake function call frame with new parameters. In memory, it looks like this:
Buffer: XXXX XXXX XXXX XXXX... Saved registers: YYYY YYYY Return address: ZZZZ = Address of libc function F2 Return address for F2: AAAA (not necessarily used, exec doesn't return) First parameter for F2: BBBB Second parameter for F2: CCCC ...
You can also return into functions specific to the program, and you can return into the middle of a function, perhaps after bypassing security checks.
As to Charles-A's question about why not use boundary checking, *is* there some reason why it's not typically used?? (at least not in C)
(A) People think it's slow. In the case of an inner loop, they might actually be right, but the correct course of action is to move the boundary check to just before the loop. (This was one of the big reasons people complained about the speed of early Java revisions. Newer ones optimize the check when they JIT, I think.)
(B) People think they've already created a sufficient boundary condition (e.g. '\0' with C strings) and don't give any thought to abnormal inputs. Too few programmers understand the concept of "defensive coding".
(C) People *do* check boundaries, but the size can be wrapped around with an integer overflow and made to pass the check. E.g., suppose that on a 16-bit system, a string that's 65,534 bytes long needs to have a 4 bytes filename suffix appended to the end, and the result is stored in a 1KB buffer. The length according to the check is 65534+4 = 65538 mod 65536 = 2, because the number wraps around to 0 when it's too big. Since 2 is less than 1KB, the check succeeds, and 64KB of data gets written to a 1KB buffer. Integer overflows are devilishly hard to program against, which is why I believe it's a huge mistake that C doesn't have any mechanism to make them raise an error of some sort on overflow (most processors support something like that, and some extra work by the compiler can fake it on those that don't).
Yes, return stacks eliminate the direct problem. They add some overhead, debugging is a bit more complicated (harder to figure out where all the pieces of a function's frame are), and there's still some risk because other local variables to the function can still be overflowed, which might trigger insecure behavior, and saved registers from the calling function can be attacked as well. Overall, though, they do mitigate the problem quite a bit. The biggest stumbling block in implementing them is trying to allocate memory for two growable stacks that can't be relocated at runtime. The current approach is to have the stack grow downward from the top of memory, and have the heap grow upward from the bottom. Two stacks would break this compromise, which would mean a return to hard limits on the maximum depth of recursive functions.
That's actually the point of all this buffer overflow protection. The programmers *should* have used a boundary check, but they forgot to, and now there's a security hole because of it, so now the OS, processor, and compiler are trying to limit the damage caused by a forgetful programmer.
I forgot to point out that you can prove this by compiling your program with an older or non-MS compiler. Write up a test C program, then compile it with Cygwin or MinGW GCC, and run it on an XP SP2 system running on a plain x86 processor. It should still overflow normally. Switch to Microsoft's compiler, and it should raise an error instead.
No, this is the stack canary in action. To emulate per-page NX on a processor without it, Windows would have to single-step all your programs, making it slower than VMware. (VMware doesn't even emulate at that level of detail.)
(Technically, it could get by without single-stepping: it could mark your NX pages no-read, then handle the page fault by checking the instruction at the fault address, emulating a MOV or similar instruction but killing the program on a RET or similar. However, that's horrendously slow, since each page fault involves two context switches (one into ring 0, one back to ring 3), which would easily slow your program by 100-fold. Your 3GHz computer would effectively max out at 300MHz.)
A stack canary is a form of protection against stack overflows. And yes, the idea is named after the canaries used in coal mines. To put it in simple terms, a normal stack during a function call might look like this:
When the buffer is overflowed, the attacker fills it with more data than it can hold. The extra data first fills the saved registers, then overwrites the return address. The attacker can simply point the return address back into the buffer, or find more diabolical means ("return into libc", a few others), to run his own code.
If a recent OS (first Linux, now Windows) is running on, say, an AMD64 system, then the entire stack is flagged with the NX (no execute) bit. If the attacker uses the normal technique of returning into the buffer, the processor will halt the program because it's trying to treat data as code without asking first. (This doesn't protect against return into libc attacks.)
However, on ordinary x86 processors like Pentium 4 or Athlon XP, there is no NX bit. So, Microsoft altered their compiler to insert stack canaries into every function. The previous stack diagram is changed to something similar to this:
Ideally, the canaries are chosen randomly each time a function is called. However, this is too slow in practice, since functions get called *a lot*, so a program will randomly choose a single canary number once at startup and reuse it.
Now the attacker can still overflow the buffer, but this time he has to overwrite the canary. If he already knows the canary, or guesses it correctly, everything works the same as in the case of an unprotected overflow. However, if he guesses wrong, the canary kicks in. To maintain the canary, there is some code inserted by the compiler at the start and end of every function. The start code inserts the canary into the stack, and the end code checks that the canary has not changed. If the canary changed, an error is triggered, and the program is halted before the function ever returns. This prevents the attacker's code from running if he doesn't know the canary number.
There are still some scenarios that aren't protected by a stack canary, but it is rather effective overall, and actually protects against a few scenarios that the NX bit doesn't cover. It doesn't help protect against heap overflows, though, although there's no reason heap canaries can't be used also. (The heap is a lot harder to explain than the stack, but a lot of programs put some or all of their buffers in heap memory instead, and the heap can be attacked as well.)
The non-executable flagging (Data Execution Prevention in MS parlance) only applies when Windows is running on an architecture that supports it, which is pretty much only AMD64 at this point. They use stuff like stack canaries to protect x86, which makes an attack harder but not impossible.
I do, in fact, research my posts before I hit "Submit". I'm fully aware of just how big the Supplementary Multilingual Plane is getting in the newest specs -- hell, the undeciphered Indus valley script made it in there, albeit only as a preliminary proposal so far. However, there are still a handful of languages out there that aren't represented, including a few obscure but living languages (unfortunately I can't recall any of them, but we're talking <100 speakers left).
I'm no expert on all the political nuances, but there are at least two groups of people that can't use Unicode.
The first is a subset of CJK (Chinese, Japanese, and Korean) speakers. CJK support has been a political minefield for years, and Unicode just made it worse. If you're not aware, each of those languages uses Chinese ideograms in its written language (Korean less so today), even though the actual pronunciations are completely different. The first mine is the PRC's creation of "Simplified Chinese" in the 1950's, and whether a character set favors Simplified or Traditional characters determines a broad swath of political implications. A second mine is how many literary characters a character set supports; to properly record classic Chinese literature, you need somewhere near 50,000 code points, but if you're just recording modern communication, you can get by with around 10,000 (Traditional) or 2,000 (Simplified). The latest mine is the Unicode Consortium's attempt at Han unification, which merged all 4 languages (counting Simplified and Traditional separately) into a single list of code points, without regard for the fact that the actual glyphs sometimes varied dramatically between languages; the expectation was that users would have the appropriate font for their local language installed, but it makes using multiple CJK languages (e.g. a list containing both Chinese and Japanese names) difficult at best and sometimes outright impossible.
The second group of people who can't use Unicode are people using languages that aren't in Unicode. Most of these are historical languages being studied by linguists, but there are even a handful of modern languages.
There are also some situations where, although Unicode works, using a different encoding is much more space-efficient. Ignoring the obvious example of the ISO-8859-N family, CJK text is very, very bulky when encoded in UTF-8 (3 to 4 bytes), but is easily represented by fixed-width 2 byte encodings, and sometimes Japanese can even be shoehorned into 1 byte per character (if it's all kana).
RoC (Republic of China) = Pre-communist government of China, kicked out into exile after the revolution. The RoC set up shop in Taiwan and still claims it's the rightful ruler over mainland China.
PRC (People's Republic of China) = Communist government of China. The PRC still claims it's the rightful ruler over Taiwan.
In practice, China and Taiwan are two different countries, but anyone with the balls to formally recognize it ends up on China's shit list. The PRC has hinted that they might go so far as go to war if the US were to publicly support Taiwanese independence. And, of course, China is a full-blown nuclear power, and has North Korea as its puppet/fall guy. That means lots of dancing around words when talking politics about the two.
(And, in case you were wondering, that's the real reason why China has been making such a big deal about starting its own space program and putting its own people on the moon. It's a public demonstration of your ICBM technology for delivering nuclear warheads, which was the reason behind the US vs. Russia space race.)
Forgot to mention, that if you want a good example of Metroid Prime's "old plus new" sound, check out the "Phendrana Ice Chapel", "Artifact Temple", "Epilogue", and "Credits" tracks -- either here or via the filesharing networks.
There have been some games in recent times that have done innovative things with music. Of the games I've played, first and foremost is Rez (and I'm actually quite surprised that neither the AA article nor any comments have mentioned it). If you've never played it, the shots you fire add beats timed to the music, the music transitions very naturally when you jump ahead to the next section of the level, parts of the stage bounce in time to the music, and the timing of the beats gives you cues for when enemies are about to appear or change strategies. It's really a tour de force on unifying music with gameplay.
Another game that brings something to the debate is Metroid Prime. Despite having a Nintendo-proclaimed "cinematic soundtrack" and relying heavily on traditional styles, it's a surprisingly innovative and memorable soundtrack that blends orchestral accompaniment with traditional Metroid musical themes and experimental synthesized instruments. It's something of a counterexample to the AA article's main point that orchestras equal imitation.
Your model for an oversight body is counter-intuitive to me in the analogy. In the human body the reason that the immune system works is because it is distributed, not centralized. Each area has the ability to respond to localized threats, and can contribute to combating holistic problems as well.
Actually, the human body DOES have a centralized clearing authority that approves new immune functions -- the thymus. It has the job of testing new white blood cells to make sure they'll fit in with the rest of the body. When the thymus fails or makes a mistake, the result is an autoimmune disorder.
By storing the content of the program, and not their silly display preferences, it would load and present to me however I had it set up to display it, not according to their preferences.
One of the obvious benefits is the end of the holy wars over brace and indentation style. Think code should be tabbed out 2 spaces instead of 4? Constantly resisting the urge to reformat everyone else's Java code to 1TBS? Want to program in C using Python-style meaningful whitespace? Not a problem. Just clicky-click on your editor preferences (or:set codingstyle=foo), and you're done.
That's freaking absurd. You can host 400,000 websites on 1 IP address. You don't need an IP per website.
One word: SSL. I mean, I love the Host: header as much as the next guy, but you can't switch SSL certificates to one with the appropriate CN based on a header which hasn't been sent yet.
That said, 400k is a *lot* of SSL-capable websites.
And just WHY should CNN, or any other news service, "push" one product over another? What possible interest could they have?
Well, maybe they could do a little mention, like:
Alternative browsers such as Netscape 7.1 and the Mozilla Project's Firefox browser are unaffected by this and many other flaws. Netscape is a fully-owned subsidiary of AOL Time Warner, the parent company of CNN.
The extension modules that come with PHP go to extraordinary lengths to keep them from being compiled independently of building a new copy of PHP, even if you're just trying to build them as extensions for an existing PHP. It's not like Perl where you can just do a perl -MCPAN -e 'install Package::Name', or Apache where you can use the APXS tool to easily build outside the Apache tree. It's *possible*, but it's extraordinarily creaky. Plus, it's impossible to install it for only one host in a virtual hosting environment, so the lack of a package namespace means *every* PHP script of *every* host has to be checked for namespace collisions.
This doesn't even touch on things like the complete lack of a unified SQL database layer like Perl's DBI. Having to rewrite your PHP app from scratch because you switched from MySQL to Postgres is *NOT* a sign of a well-thought-out language.
I have 'EVERY' idea what I'm talking about. I've f***ing written loadable modules in C for PHP -- which, BTW, has absolutely no namespace support other than manually naming every function "foo" as "module_foo" (and thus being unable to shorten it by importing the namespace). I've also read the entire PHP manual from start to finish. Don't go telling me that I'm not aware of PHP's language "features".
Displays have approximately 100 DPI (dots per inch) of resolution. Printing on a cheapie inkjet has 300 DPI. Printing on a high-quality but still consumer-level laser printer tops out around 1200 DPI. Each time you double the DPI, you need 4 times as many pixels to attain it.
Or perhaps it's simply another language written by people who do not want to have the issues that perl has, and perhaps want a language that lends itself to knowing what you were doing 15 minutes after you started doing it.
Oh, come on. On what planet does it make sense to require e.g. generating SWF (Macromedia Flash) files to either be built in to the core language, or excluded altogether requiring a recompile to install that functionality?
Is adding a use Module; line *really* that much harder for a newbie? He/She still needs to read the documentation anyway to figure out what the available function calls are.
You wouldn't directly. You'd allocate a buffer from the heap, then push a pointer to it on the stack.
The big one is return into libc. Since the C library contains valid functions that are already marked as code, all you have to do is find one that does what you like, e.g. something from the exec family. As you're overflowing, you overwrite not just the return address, but the memory after it, creating a fake function call frame with new parameters. In memory, it looks like this:
You can also return into functions specific to the program, and you can return into the middle of a function, perhaps after bypassing security checks.
(A) People think it's slow. In the case of an inner loop, they might actually be right, but the correct course of action is to move the boundary check to just before the loop. (This was one of the big reasons people complained about the speed of early Java revisions. Newer ones optimize the check when they JIT, I think.)
(B) People think they've already created a sufficient boundary condition (e.g. '\0' with C strings) and don't give any thought to abnormal inputs. Too few programmers understand the concept of "defensive coding".
(C) People *do* check boundaries, but the size can be wrapped around with an integer overflow and made to pass the check. E.g., suppose that on a 16-bit system, a string that's 65,534 bytes long needs to have a 4 bytes filename suffix appended to the end, and the result is stored in a 1KB buffer. The length according to the check is 65534+4 = 65538 mod 65536 = 2, because the number wraps around to 0 when it's too big. Since 2 is less than 1KB, the check succeeds, and 64KB of data gets written to a 1KB buffer. Integer overflows are devilishly hard to program against, which is why I believe it's a huge mistake that C doesn't have any mechanism to make them raise an error of some sort on overflow (most processors support something like that, and some extra work by the compiler can fake it on those that don't).
Yes, return stacks eliminate the direct problem. They add some overhead, debugging is a bit more complicated (harder to figure out where all the pieces of a function's frame are), and there's still some risk because other local variables to the function can still be overflowed, which might trigger insecure behavior, and saved registers from the calling function can be attacked as well. Overall, though, they do mitigate the problem quite a bit. The biggest stumbling block in implementing them is trying to allocate memory for two growable stacks that can't be relocated at runtime. The current approach is to have the stack grow downward from the top of memory, and have the heap grow upward from the bottom. Two stacks would break this compromise, which would mean a return to hard limits on the maximum depth of recursive functions.
That's actually the point of all this buffer overflow protection. The programmers *should* have used a boundary check, but they forgot to, and now there's a security hole because of it, so now the OS, processor, and compiler are trying to limit the damage caused by a forgetful programmer.
I forgot to point out that you can prove this by compiling your program with an older or non-MS compiler. Write up a test C program, then compile it with Cygwin or MinGW GCC, and run it on an XP SP2 system running on a plain x86 processor. It should still overflow normally. Switch to Microsoft's compiler, and it should raise an error instead.
No, this is the stack canary in action. To emulate per-page NX on a processor without it, Windows would have to single-step all your programs, making it slower than VMware. (VMware doesn't even emulate at that level of detail.)
(Technically, it could get by without single-stepping: it could mark your NX pages no-read, then handle the page fault by checking the instruction at the fault address, emulating a MOV or similar instruction but killing the program on a RET or similar. However, that's horrendously slow, since each page fault involves two context switches (one into ring 0, one back to ring 3), which would easily slow your program by 100-fold. Your 3GHz computer would effectively max out at 300MHz.)
A stack canary is a form of protection against stack overflows. And yes, the idea is named after the canaries used in coal mines. To put it in simple terms, a normal stack during a function call might look like this:
When the buffer is overflowed, the attacker fills it with more data than it can hold. The extra data first fills the saved registers, then overwrites the return address. The attacker can simply point the return address back into the buffer, or find more diabolical means ("return into libc", a few others), to run his own code.
If a recent OS (first Linux, now Windows) is running on, say, an AMD64 system, then the entire stack is flagged with the NX (no execute) bit. If the attacker uses the normal technique of returning into the buffer, the processor will halt the program because it's trying to treat data as code without asking first. (This doesn't protect against return into libc attacks.)
However, on ordinary x86 processors like Pentium 4 or Athlon XP, there is no NX bit. So, Microsoft altered their compiler to insert stack canaries into every function. The previous stack diagram is changed to something similar to this:
Ideally, the canaries are chosen randomly each time a function is called. However, this is too slow in practice, since functions get called *a lot*, so a program will randomly choose a single canary number once at startup and reuse it.
Now the attacker can still overflow the buffer, but this time he has to overwrite the canary. If he already knows the canary, or guesses it correctly, everything works the same as in the case of an unprotected overflow. However, if he guesses wrong, the canary kicks in. To maintain the canary, there is some code inserted by the compiler at the start and end of every function. The start code inserts the canary into the stack, and the end code checks that the canary has not changed. If the canary changed, an error is triggered, and the program is halted before the function ever returns. This prevents the attacker's code from running if he doesn't know the canary number.
There are still some scenarios that aren't protected by a stack canary, but it is rather effective overall, and actually protects against a few scenarios that the NX bit doesn't cover. It doesn't help protect against heap overflows, though, although there's no reason heap canaries can't be used also. (The heap is a lot harder to explain than the stack, but a lot of programs put some or all of their buffers in heap memory instead, and the heap can be attacked as well.)
The non-executable flagging (Data Execution Prevention in MS parlance) only applies when Windows is running on an architecture that supports it, which is pretty much only AMD64 at this point. They use stuff like stack canaries to protect x86, which makes an attack harder but not impossible.
I do, in fact, research my posts before I hit "Submit". I'm fully aware of just how big the Supplementary Multilingual Plane is getting in the newest specs -- hell, the undeciphered Indus valley script made it in there, albeit only as a preliminary proposal so far. However, there are still a handful of languages out there that aren't represented, including a few obscure but living languages (unfortunately I can't recall any of them, but we're talking <100 speakers left).
I'm no expert on all the political nuances, but there are at least two groups of people that can't use Unicode.
The first is a subset of CJK (Chinese, Japanese, and Korean) speakers. CJK support has been a political minefield for years, and Unicode just made it worse. If you're not aware, each of those languages uses Chinese ideograms in its written language (Korean less so today), even though the actual pronunciations are completely different. The first mine is the PRC's creation of "Simplified Chinese" in the 1950's, and whether a character set favors Simplified or Traditional characters determines a broad swath of political implications. A second mine is how many literary characters a character set supports; to properly record classic Chinese literature, you need somewhere near 50,000 code points, but if you're just recording modern communication, you can get by with around 10,000 (Traditional) or 2,000 (Simplified). The latest mine is the Unicode Consortium's attempt at Han unification, which merged all 4 languages (counting Simplified and Traditional separately) into a single list of code points, without regard for the fact that the actual glyphs sometimes varied dramatically between languages; the expectation was that users would have the appropriate font for their local language installed, but it makes using multiple CJK languages (e.g. a list containing both Chinese and Japanese names) difficult at best and sometimes outright impossible.
The second group of people who can't use Unicode are people using languages that aren't in Unicode. Most of these are historical languages being studied by linguists, but there are even a handful of modern languages.
There are also some situations where, although Unicode works, using a different encoding is much more space-efficient. Ignoring the obvious example of the ISO-8859-N family, CJK text is very, very bulky when encoded in UTF-8 (3 to 4 bytes), but is easily represented by fixed-width 2 byte encodings, and sometimes Japanese can even be shoehorned into 1 byte per character (if it's all kana).
FYI...
In practice, China and Taiwan are two different countries, but anyone with the balls to formally recognize it ends up on China's shit list. The PRC has hinted that they might go so far as go to war if the US were to publicly support Taiwanese independence. And, of course, China is a full-blown nuclear power, and has North Korea as its puppet/fall guy. That means lots of dancing around words when talking politics about the two.
(And, in case you were wondering, that's the real reason why China has been making such a big deal about starting its own space program and putting its own people on the moon. It's a public demonstration of your ICBM technology for delivering nuclear warheads, which was the reason behind the US vs. Russia space race.)
No offense meant, but to have a lot of respect for Kline, you'd have to have a lot of ignorance for Kline's actions as AG. I say this as a fellow Kansan.
Forgot to mention, that if you want a good example of Metroid Prime's "old plus new" sound, check out the "Phendrana Ice Chapel", "Artifact Temple", "Epilogue", and "Credits" tracks -- either here or via the filesharing networks.
... are somewhat exaggerated.
There have been some games in recent times that have done innovative things with music. Of the games I've played, first and foremost is Rez (and I'm actually quite surprised that neither the AA article nor any comments have mentioned it). If you've never played it, the shots you fire add beats timed to the music, the music transitions very naturally when you jump ahead to the next section of the level, parts of the stage bounce in time to the music, and the timing of the beats gives you cues for when enemies are about to appear or change strategies. It's really a tour de force on unifying music with gameplay.
Another game that brings something to the debate is Metroid Prime. Despite having a Nintendo-proclaimed "cinematic soundtrack" and relying heavily on traditional styles, it's a surprisingly innovative and memorable soundtrack that blends orchestral accompaniment with traditional Metroid musical themes and experimental synthesized instruments. It's something of a counterexample to the AA article's main point that orchestras equal imitation.
...whose name means "giant shapeless penis".
Your model for an oversight body is counter-intuitive to me in the analogy. In the human body the reason that the immune system works is because it is distributed, not centralized. Each area has the ability to respond to localized threats, and can contribute to combating holistic problems as well.
Actually, the human body DOES have a centralized clearing authority that approves new immune functions -- the thymus. It has the job of testing new white blood cells to make sure they'll fit in with the rest of the body. When the thymus fails or makes a mistake, the result is an autoimmune disorder.
Obligatory Sean Connery Link
By storing the content of the program, and not their silly display preferences, it would load and present to me however I had it set up to display it, not according to their preferences.
One of the obvious benefits is the end of the holy wars over brace and indentation style. Think code should be tabbed out 2 spaces instead of 4? Constantly resisting the urge to reformat everyone else's Java code to 1TBS? Want to program in C using Python-style meaningful whitespace? Not a problem. Just clicky-click on your editor preferences (or :set codingstyle=foo), and you're done.
That's freaking absurd. You can host 400,000 websites on 1 IP address. You don't need an IP per website.
One word: SSL. I mean, I love the Host: header as much as the next guy, but you can't switch SSL certificates to one with the appropriate CN based on a header which hasn't been sent yet.
That said, 400k is a *lot* of SSL-capable websites.
And just WHY should CNN, or any other news service, "push" one product over another? What possible interest could they have?
Well, maybe they could do a little mention, like:
Alternative browsers such as Netscape 7.1 and the Mozilla Project's Firefox browser are unaffected by this and many other flaws. Netscape is a fully-owned subsidiary of AOL Time Warner, the parent company of CNN.
The extension modules that come with PHP go to extraordinary lengths to keep them from being compiled independently of building a new copy of PHP, even if you're just trying to build them as extensions for an existing PHP. It's not like Perl where you can just do a perl -MCPAN -e 'install Package::Name', or Apache where you can use the APXS tool to easily build outside the Apache tree. It's *possible*, but it's extraordinarily creaky. Plus, it's impossible to install it for only one host in a virtual hosting environment, so the lack of a package namespace means *every* PHP script of *every* host has to be checked for namespace collisions.
This doesn't even touch on things like the complete lack of a unified SQL database layer like Perl's DBI. Having to rewrite your PHP app from scratch because you switched from MySQL to Postgres is *NOT* a sign of a well-thought-out language.
I have 'EVERY' idea what I'm talking about. I've f***ing written loadable modules in C for PHP -- which, BTW, has absolutely no namespace support other than manually naming every function "foo" as "module_foo" (and thus being unable to shorten it by importing the namespace). I've also read the entire PHP manual from start to finish. Don't go telling me that I'm not aware of PHP's language "features".
300 dpi on a 4" x 6" photo is 2.1 MPixel.
Yeah, but where's your overhead for image post-processing?
Displays have approximately 100 DPI (dots per inch) of resolution. Printing on a cheapie inkjet has 300 DPI. Printing on a high-quality but still consumer-level laser printer tops out around 1200 DPI. Each time you double the DPI, you need 4 times as many pixels to attain it.
Or perhaps it's simply another language written by people who do not want to have the issues that perl has, and perhaps want a language that lends itself to knowing what you were doing 15 minutes after you started doing it.
Oh, come on. On what planet does it make sense to require e.g. generating SWF (Macromedia Flash) files to either be built in to the core language, or excluded altogether requiring a recompile to install that functionality?
Is adding a use Module; line *really* that much harder for a newbie? He/She still needs to read the documentation anyway to figure out what the available function calls are.