On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote:
> which I interpret to mean that after using -fstack-protector-all and
> removing prelink, SELinux would become obsolete because no executable
> can be exploited.
I would say there is a place for SE Linux even if we compiled everything with
"all" because FORTIFY_SOURCE coverage is not absolute. For example, about a
month ago i ran the following test:
procs=`ls /proc | grep '^[0-9]' | sort -n`
for p in $procs
do
res=`cat /proc/$p/maps 2>/dev/null | awk '$2 ~ "wx" { print $2 }'`
if [ x"$res" != "x" ] ; then
cat /proc/$p/cmdline | awk '{ printf "%-35s\t", $1 }'
printf "%s\n" "$p"
fi
done
What this does is display the programs with Writable and Executable memory.
All Fedora desktops except Mate have WX memory. (I checked KDE, Gnome,
Cinnamon, and Mate.) WX memory is dangerous because the normal exploit pattern
is:
1) Allocate executable memory
2) Copy shell code into it
3) Jump to shell code
4) Profit!
The WX memory on virtually all the desktops means Step 1 is completed. All an
attacker needs to do is copy payload to Wx memory and jump to it. SE Linux is
the last line of defence. Of course to be effective, this means that SE Linux
has to have policy around the same applications that parse untrusted media so
that when they are exploited it knows abnormal behavior.
> > And there is no cutoff size with -fstack-protector-all.
All really is all. There is no cutoff. (There is a cutoff for the regular stack-
protector, but we have a good default.) It does not help for heap related
objects, though. What I would prefer rather than "all" is the "strong" patch.
If you have a void function with no local variables, "all" will place a canary
even though one is not needed. However, "strong" will not and that will make
the program run a bit faster. The "strong" patch really represents a good
balance between speed and covering everything that matters.
And at Infiltrate 2013, one new technique for exploitation that was discussed
was pivoting the stack pointer to something like the heap where you might have
executable permissions. I think this was discussed in context to exploiting
ARM systems, but in a post PC world this will be increasingly important.
Also demonstrated at Infiltrate last week was the next kind of attack that
occurs even when you do things nearly perfect. Windows 8 has vastly improved
exploit countermeasures (there is a presentation at BlackHat 2012). For
example, it has guard pages between memory allocations, they changed heap
allocations < 16K (which is the majority of all uses) to be bit mapped based
so there is no possibility heap state attacks. It also randomly assigns blocks
so that behavior is non-deterministic. Sounds hard to exploit?
It turns out there is a weakness. The medium sized allocator has predictable
behavior and its memory gets reused. What the attack demonstrated was that an
attacker can use the Feng Shui technique to cause the placement of memory
allocation of a structure holding a function pointer right beside a vulnerable
buffer so that they can modify the function pointer and then wait for it to get
used. Eric also demonstrated that he could do this in the Windows 8 kernel,
too. So, watch out for function pointers, too. :-)
-Steve
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
