Re: [gentoo-hardened] Ports Security

[Alexander Gabert]

hello,

On Sat, 2003-09-06 at 16:52, Jan Krueger wrote:
> I would like to present you an example showing how silly source scanning can
> be if done without thought:
>
> qmail and exim
>
> flawfinder reports more flaws in qmail (10 or so) then in exim (only 1).
> If one would make a decision based on the flawfinder output only, one would
> install exim.
>
> Offcourse if one compares the number of actual security holes found in exim to
> those found in qmail, one would install qmail.
don't think so.
there must be a reason for flawfinder to find so much "problems" in
qmail.

>
> So i understand source code analysis as the first step only to create
> something for developers and admins/users that is able to guide them in
> security questions.
there is nothing that can "guide" you, in my opinion.
the program that checks for flaws must print out a list of "problematic"
code pieces based on real facts.
the threat is real, so must be the defense mechanisms.
no "guidance" or "counseling" needed for the user to be influenced.
>
> some of the next steps i can imagin are:
> - a ports security policy :)
well, devs are notorious overworked ppl.
you would not rush in open doors.
but i appreciate your thoughts and will try to make up my mind.
>
> - suid scans
>
> - scans of binaries
not possible.
writing disassemblers that make assumptions is bad practice.
>
> - complexity analysis (we got the code, we got the binaries - if there was
> createt only 1 biiig binary out of al the code we know that the potential
> security impact is higher (exim)  then if there would have been created
> several small binaries (assuming modularity, like qmail), etc.
qmail is not more secure than exim, if the author says so, he may say
so.  i myself do not believe it, should be careful what you interpret.

the truth is that packages like qmail deserve the high reputation only
from the people who are using it.

>
> - dynamic meta-information from external sources (CERT, GLSA Database)

very good point, we could make a "link" to bugs found regarding the
source URI.
which would resolve in a mapping: CERT/Bugtraq <-> SRC_URI

> This would result in:
> # emerge -p somemta
> Calculating dependencies ...done!
>  ebuild information | version             | hardened | CERT | GLSA
> [ebuild  N   ]        net-mail/exim-4.14    -          5      2
>
> # emerge -p --secinfo somemta
>
> *  net-mail/somemta
>       Latest version available: 4.14
>       Latest version installed: [ Not Installed ]
>       Size of downloaded files: 1,531 kB
>       Homepage:    http://www.somemta.org/
>       ebuild Maintainer: someone@×××××××××.org
>       Description: A highly configurable, drop-in replacement for sendmail
>
>       Package is part of gentoo hardened : no
>       CERT Security Advisories for somemta found : 5
>       CERT affecting this version of somemta found : 1
>       GLSA for somemta found : 2
>       GLSA affecting this version of somemta found : 1
>
>       Warnig: This version is affected by several security advisories.
>       It is recommended to not install this version!
>       You may try emerge sync or search at bugs.gentoo.org to get a newer
>       version or contact the ebuild maintainer
>
> and while you do
> # emerge somemta
> you get additional information:
> * source code analysis report:
> *  1 potential security flaw found
> ....
>
> * compexity analysis report:
> *  package seems to fairly complex, possible security impact: medium
>
> * suid scan report:
> * the software would like to install the following suids
> * 1) /usr/sbin/exim      suid root
> * 2) /usr/sbin/blalaber  suid mail
> What would like to do?
> 	-3) install all as shown
>         -1) install all without suid
> 	or choose number of binary:
>
> ofcourse, this all can be enhanced and so on, thats why i put it here :)

thank you,

a last thought about your binary scanning.

pipacs is the brain behind PaX who is working out the logic for
protecting accesses.

the holy grail is "full bounds checking" which means basically that you
can watch, control AND limit any arbitrary (random, going everwhere)
memory address write or read by the running program.
the running program has 4GB open memory with 1GB of the 4GB is kernel
memory.

even stackguards preventing direct linear overwriting of addresses can
be "circumenvented" as we all know.
even address space layout randomization, basically moving round and
round of ELF segments and making the memory address relocations not
writable with PIC compilation, can be information leaked.

it is not possible to employ bounds checkers like the "mudflap" gcc or
other solutions.

it is just a compromise between speed and security.

you inspired me and what has come into my mind is some kind of "hybrid"
solution where we run the preprocessed source through some kind of
"bounds checking sandbox" which evaluates the possible program flows in
terms of trees (gcc people can explain more about this) and evaluate the
pointers at each point of execution.

remember that the program is not yet binary and is not actually _run_.

it is just a funky parsing of the CPP preprocessed source, or later at
RTL stage, in the gcc.

in so called "red areas" the gcc would put full bounds checking in.
in other areas that appear to be "safe" or "green" in the preprocessor
dry run, the bounds checks can be left out for speedup.

anyway, this would significantly increase compile time by factors of two
or more.  think about compiling xfree86 with that gcc.

instead of 8 hours on a hppa machine it would take 20 hours or more.

but it would have no or little impact on the final binary because the
speed is gained from the "dry run" in the gcc CPP stage.

have fun,
	-pappy

>
> Jan
>



--
gentoo-hardened@g.o mailing list