Re: Looking for external program invocations

[Mark Hobley]

Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> but this can:
>
> syst\
> em("causedamage.sh");
>

So ideally we need a way of causing the preprocessor to warn that the code
causes invocation of external programs and to identify the lines of source code
where this takes place. I wonder if the GNU C preprocessor has that
capability...

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

[Richard Tobin]

In article <oi9047-...@neptune.markhobley.yi.org>,
Mark Hobley <markh...@hotpop.donottypethisbit.com> wrote:

>> syst\
>> em("causedamage.sh");

>So ideally we need a way of causing the preprocessor to warn that the code
>causes invocation of external programs and to identify the lines of source code
>where this takes place. I wonder if the GNU C preprocessor has that
>capability...

You can compile each file and then run something on the object code
(nm for unix-like systems) that will show you the names of external
functions referred to. You may also be able to determine the line
numbers, but even without that it will help you identify which files
contain calls to the functions you are concerned about.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[Ben Bacarisse]

markh...@hotpop.donottypethisbit.com (Mark Hobley) writes:

> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> but this can:
>>
>> syst\
>> em("causedamage.sh");
>>
>
> So ideally we need a way of causing the preprocessor to warn that the code
> causes invocation of external programs and to identify the lines of
> source code

I would take Eric's advice. I'd do this after the compile not
before. Using system tools you can see what functions are linked to
the interpose your own wrappers wound the ones you care about.

<snip>
--
Ben.

[Jerry Peters]

In comp.os.linux.development.apps Mark Hobley <markh...@hotpop.donottypethisbit.com> wrote:
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> but this can:
>>
>> syst\
>> em("causedamage.sh");
>>
>
> So ideally we need a way of causing the preprocessor to warn that the code
> causes invocation of external programs and to identify the lines of source code
> where this takes place. I wonder if the GNU C preprocessor has that
> capability...
>
> Mark.
>

#define system <something that will cause an error>

IIRC there are # directives that will cause a warning.

Jerry

[Jasen Betts]

On 2010-02-06, Mark Hobley <markh...@hotpop.donottypethisbit.com> wrote:
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> but this can:
>>
>> syst\
>> em("causedamage.sh");
>>
>
> So ideally we need a way of causing the preprocessor to warn that the code
> causes invocation of external programs and to identify the lines of source code
> where this takes place. I wonder if the GNU C preprocessor has that
> capability...

what are you hoping to gain by banning external programs?

FWIW you also need to ban exec*, popen, and probably others,

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Mark Hobley]

Nobody <nob...@nowhere.com> wrote:
> You can detect execution at run-time by tracing the execve system call.
> Anything which executes a program (system, popen, the other exec*
> functions, etc) will eventually go through here.

Brilliant. Could I also do this at audit time or compile time?

> You may also want to trace run-time loading of libraries, in which case
> you should trace calls to mmap() with the PROT_EXEC flag.

Again, this sounds good. If I can detect these at audit time or compile time
that would be great.

[Mark Hobley]

In comp.os.linux.development.apps Jasen Betts <ja...@xnet.co.nz> wrote:
> what are you hoping to gain by banning external programs?

I am trying to audit open source packages for external program invocation
vulnerabilities. (such as invocation of arbitrary commands, and others).

I am also documenting any dependencies on external programs.

I have a program that requires a fix.

[Flash Gordon]

Mark Hobley wrote:
> Nobody <nob...@nowhere.com> wrote:
>> You can detect execution at run-time by tracing the execve system call.
>> Anything which executes a program (system, popen, the other exec*
>> functions, etc) will eventually go through here.
>
> Brilliant. Could I also do this at audit time or compile time?
>
>> You may also want to trace run-time loading of libraries, in which case
>> you should trace calls to mmap() with the PROT_EXEC flag.
>
> Again, this sounds good. If I can detect these at audit time or compile time
> that would be great.

This is really nothing to do with C and everything to do with the Linux
tools available. So please drop comp.lang.c off the cross-posts.

It's probably not topical on the gcc groups either, since it is not
about the compiler or how to use it.
--
Flash Gordon

[Jasen Betts]

On 2010-02-07, Mark Hobley <markh...@hotpop.donottypethisbit.com> wrote:
> Nobody <nob...@nowhere.com> wrote:
>> You can detect execution at run-time by tracing the execve system call.
>> Anything which executes a program (system, popen, the other exec*
>> functions, etc) will eventually go through here.
>
> Brilliant. Could I also do this at audit time or compile time?
>
>> You may also want to trace run-time loading of libraries, in which case
>> you should trace calls to mmap() with the PROT_EXEC flag.
>
> Again, this sounds good. If I can detect these at audit time or compile time
> that would be great.

you can compile with -E and parse that output to get a list of the
functions called

(or perhaps use ldd on the binary to get a list of the symbols referenced)

then you just have to choose which functions are allwoed and which are
not.

It's likely you'll need to to ban several usually harmless system
calls like mmap and ldopen just because they could be abused.

If you can't accept that your task devolves into the halting problem,
which is generally considered to be insoluble.