cdecl, syscall and the x86-64 conventions… you’ll need them for this course!The gets() function from the C standard library is considered dangerous: explain why, how it could be exploited and what a programmer should use instead? (5 marks)
Explain how a system call is made on Linux for a 32bit X86 system (5 marks)
Different operating systems have taken different approaches to handling dangerous standard library functionality (like the ~%n~ format string specifier). Alice says these features should be removed as they can be dangerous, but Bob says that they cannot be removed because legacy code may rely on them and in any case it is not the operating systems job to protect the user from their own mistakes. Discuss (i.e. both sides of the argument with a conclusion) who is right and the relative tradeoffs (15 marks)
Answers (do not check this before you try to answer the exercices alone)
Gets reads from standard input into a buffer pointed to by its first argument (1).
It is considered dangerous because if the input is larger than the buffer itself then gets will continue writing (1) over adjacent memory (1).
If adjacent memory contains control flow data (eg return addressess) then this can be over written and control flow hijacked leading to arbitrary code execution (1). Don’t use gets… use bounded variants instead (1).
Syscall number in eax (1). Arguments in ebx ecx edx esi edi (1) Additional arguments (if necessary via the stack) (1) Call int 0x80 to trigger the syscall (1) Return code in eax (1)
Breaking legacy code is always problematic, and we should usually try and avoid it. That said, in this case there may be an argument for it as %n is relatively obscure and it opens up several opportunities for abuse. Code that does use it could be rewritten relatively trivially for most cases, even for a relatively inexperienced programmer. Looking at the system log for my OpenBSD system which logs uses I can’t see any applications that actually use it in my day to day use so breaking it may be justified.
That said, there may be the odd legitimate use. And where source code is long since lost it would be a shame to break others apps just for the sake of a bug which may not be exploitable in there software. It is still a part of the C standards (and always will be of the legacy standards)… and altering them is not in the remit of most OS vendors, and would set a dangerous precedent and incourage incompatibility between OSs.
Perhaps warning on its use more and more vociferously is the right approach in the short term (compiler and user warnings). Notifiying users that their apps will imminently be broken and pushing standards organisations to kill the feature in the longer term and empirically measuring how much actually depends on it before ultimately ditching it is the right approach long term? Ultimately though, arguments for getting rid of it outweigh the benefits.