CLONE_NEWUSER trickery: CVE-2013-1858

Recent kernels (3.8+ something) introduced a feature called
user-namespaces (user-ns, CLONE_NEWUSER flag)
in which you can have your own UID 0.
Think of it as a container solution, so you can
set up compartments on a host. A nice thing,
but it has some security implications. In particular
if you mix this feature with CLONE_FS, which means
that the file-system state is shared between the
containers (e.g. processes). You suddenly get this:

The problem here is that parent and child share the
FS info (the chroot in this case), but only the child
has got its own user-ns. Since it has the
capability to do the chroot() in its own user-ns,
it will succeed doing the chroot() syscall but due to
CLONE_FS, it will also affect the parent.
Parent however stays in the init user-ns (the user-ns
that is default upon boot and the namespace where you
want to have root).
Getting a rootshell from inside a user controlled chroot
with help from outside processes is straight forward.

The xSports can be found here.

Update:
A CVE has been assigned (CVE-2013-1858) and a patch was made.

c25k problem solved

Although the c10k problem is not really a problem in
Computer Science anymore, I successfully solved the
c25k problem (and I am not talking about exploit prices)
for myself.

lophttpd can handle even more connections on a commodity PC,
single core, without connection drops. If your network equipment 
is just good enough (GBit patch cable!:)

I added a new -s switch that lets you experiment with different
scheduling strategies if the TCP send buffers start to fill.
Nevertheless, as poll() will not report a POLLOUT revent
if the TCP send buffer is full, the none stragegy should just be fine. 
Other strategies are minimize (reduce chunksize to minimum)
or suspend (temporarily remove client from POLLOUT list, if
TCP send buffer has data from last send). In particular the
suspend strategy may be of interest, as it reduces the
amount of poll events that the kernel needs to check for.
However, I could not measure any real benefit. Probably one
reason more to say that c10k is not a problem anymore since
quite a lot of time.

Interestingly: lophttpd, if under load, can even utilize
more than 100% CPU:

lophttpd caching trickery

I added 404-caching to lophttpd, in the hope that
it will result in overall speedup if a lot of clients
try to fetch non-existing files (favicon.ico etc.)

The key for the cache is the first line that is sent,
so once we see this request again, we dont need to parse the
entire header, decode the pathname and stat() it before we send
the error reply. Good, eh?

Valentine pam_fprintd trickery

Anyone can give your finger by spoofing DBUS signals
to pam_fprintd, effectively bypassing fprintd authentication.
Tested with fprintd 0.41.
darklena is the PoC and the authors have been informed.

Its probably about time to check dbus-glib usage or usage
of DBUS signals in privileged code in general.

[Update:] successfully tested on a vanilla FC16 setup with
fprintd installed from repository and SELinux target config
left as-is:

grep vs. grab

I pushed my experimental grep version to github.
It features only small amount of options, but it speeds
out grep's on large directory trees, in particular if
you have a fast HDD or SSD, where you can be as
twice as fast.

What is a dzug?

I moved the dzug.c from the null directory to xSports,
where it actually belongs to.

What is a D-Zug? Besides being an exploit for CVE-2012-3524,
a D-Zug (german: Durchgangs-Zug) was a fast kind of train
in the 70's and 80's. Nowadays its obsoleted by high speed
trains like ICE (similar to TGV in France).
dzug.c, also kind of a 80's style of living, integrates a lot of
attack vectors to proof CVE-2012-3524 exploitable.
There exist a lot of flavors of dzug.c, so
if this PoC version is not working for you, it means
indeed nothing. Its also not bound to Linux. Theoretically any
UNIX running DBUS is at risk.

New Android lophttpd binaries

I just compiled lophttpd 0.98 for Android
(without SSL support). Available here.
Nice, isn't it?

lophttpd https trickery

After better separating the client state machines
inside lophttpd yesterday, by encapsulating the
send and recv functions, it was easy to add HTTPS
support into lophttpd today (TLSv1 actually).
Everything works as normal, single threaded and non-blocking.
You will of course lose some performance compared to
plain sockets (as with any crypto) and also the sendfile() needs to be
emulated, but it should still give good performance.

I've got a new smart phone

See above! :p

I get a lot of comments about old Android jailbreaks,
but I can just repeat myself: If they are not working,
there is little chance I can help you. The bugs
are just fixed over a year ago. Thats the nature of
a jailbreak.

lophttpd trickery

I made some optimizations for lophttpd to dynamically
adjust the chunksize that is passed to sendfile().
Its based on the amount of data that is already
in the TCP send queue. The problem is that the web
server can be too fast in pushing data to the client,
so the send queue starts filling until its full and
the connection times out and is dropped as poll() wont
report possible events on it. You can adjust your send
buffer sizes (up to some extent), but increasing the timeout is no good idea,
as evil clients might just not read the pending data.
This solution avoids that and still gives you enough tuning
parameters (-S, -N, -DSTATIC_SEND_SIZE_COMPUTATION) in case
you know better.:D Much of the performance parameters
depend on the actual hardware/network configuration
(fast CPU vs. slow network, fast CPU and Gigabit LAN,
slow receivers etc. etc.). For few connections like
1000 simultaneous downloads, this is no issue at all.
The fun begins with 10k connections and its not about
CPU usage, but having as few connection drops
as possible for long lasting downloads. However the
default values should fit for most scenarios.


If you have a good test environment for c10k, let me know.