|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Crispin Cowan (crispin
WIREX.COM)Date: Mon Apr 02 2001 - 18:46:57 CDT
Makoto Iwamura wrote:
> Crispin Cowan wrote:
> >The Immunix team, in collaboration with Mike Frantzen and Jamie Lokier, has
> >developed a tool called FormatGuard that protects against printf format
> Yes, I know FormatGuard. I want to let you know this idea and get your
> suggestion and comments, and so I append your address to BCC.
Sorry, I figured that out about an hour after I sent my post.
> >So you're dropping an argument count onto the stack as an argument? How do
> >you keep standard printf from interpreting it as an actual argument?
>
> No, we don't drop it onto stack. If we do so, the layout of the stack is changed
> and we cannot keep standard printf from interpreting it as an actual argument.
Agreed.
> >This attempts to solve the problem of a protected printf library being called
> >by a standard program, but not the other way around. However, since varargs
> >defines arguments as being of completely arbitrary type, I don't understand
> >how the protected printf avoids accidentally interpreting an actual argument
> >as an argument count.
>
> Maybe you have already understood. The protected printf doesn't interpret an
> argument on the stack to get an argument count. An argument count exists on
> the code-segment.The protected printf finds <mark> and gets an argument count.
> Surely, <mark> must be a rare byte sequence in the machine code. If not, the
> protected printf recognizes a byte sequence which is not an argument count
> as an argument count.
Ok. Assuming that <mark> is some kind of encoding such that protectec printf can
determine whether it is there or not, and standard printf is not confused by <mark>
being present, then this seems to have solved the 2-way compatibility problem. Now
you're only stuck with the usual problems incurred by writing to the code segment
:-) These would be:
* Can't ROM the code. Classically not a problem for the kind of applications
that get ROM'd, but as Linux moves into the embedded computing space, this
will become a bigger issue.
* No recursion. Not a big problem for printf. Might be a bigger problem for
some other kind of varargs function that does need recursion.
* Questionable reentrancy. Can you run two copies of the program from one
shared memory image? In particular, can you use the protected printf calls
when compiling code for shared libraries? Its unclear to me whether the
argument count is completely static with respect to the call site. If so,
then it doesn't matter what context it is called from, and you get reentrancy
for free. If not, then the argument count needs to be moved into some kind of
per-process or per-thread context to support reentrant execution of shared
code.
Crispin
-- Crispin Cowan, Ph.D. Chief Research Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]