We deliver. Worldwide. Up to 0x743c times. And if you
are still not there, we return to libc.
You just noticed it, there is a new front pic online. I'll rotate
this within the next months to show cool and the gang
in different positions inside the cloud. The experienced
reader also noticed that the shirts are all made of valid
RPM switches and indeed the most important ones.
While I myself will definitely keep up with mobile stuff, our
origin are servers and the code running there. We deliver
stable, fast and secure services. If you have any problems
with your server or code, just call us.
Thursday, December 8, 2011
Tuesday, November 29, 2011
me hubbing and gitting on github
As of today you can also find me on github.
I am testing how good or bad it performs for my own projects.
For now, I made lophttpd a public repo where you can
watch the development process.
My openwall site and other places where I used to put code
stay the same and I will continue to upload .tgz files.
I am testing how good or bad it performs for my own projects.
For now, I made lophttpd a public repo where you can
watch the development process.
My openwall site and other places where I used to put code
stay the same and I will continue to upload .tgz files.
Friday, November 25, 2011
Censorship
In this' blog survey "Do you like surveys?", too many people voted that I am an idiot, rather than they dislike surveys (less amount
than people who like surveys though) so I do it like middle east
dictatorship: I just cancel it :P
than people who like surveys though) so I do it like middle east
dictatorship: I just cancel it :P
Tuesday, November 8, 2011
openpam trickery
While reviewing an entirely different server side component
of some code, I came across a funny vulnerability inside
OpenPAM (note that this is different from Linux-PAM)
as used in FreeBSDor Solaris. Yet, I only tested it on
a FreeBSD 8.1 machine. The bug is that a program,
namely kcheckpass, which is suid to root, is calling
pam_start() with a user provided argument which makes
the PAM stack parse user owned
config files which ends in loading of user
provided DSO's. WTF?!
Interestingly, OpenPAM recently introduced a filter for
the service name via
http://trac.des.no/openpam/changeset/478/trunk/lib/openpam_configure.c
commit but I dont think that any BSD or so vendor is
aware of it.
A really trivial PoC exploit can be found here.
[Update:] Solaris is not using OpenPAM (at least the OpenSolaris
version I checked), but I could not find code that strips
off certain character sequences. As the PAM setup is different
from the /etc/pam.d we know it is possible that there are no
consequences if the service argument is not filtered.
However a lot of BSD derivates
use OpenPAM and OSX as well. The question is whether one can
find a vector different than the kcheckpass which is usually
found with all KDE3 and KDE4 installs.
If you can confirm vulnerability on any Solaris or non-FreeBSD
machine, please let me know. Also if you found out how OSX
can be exploited this way.
of some code, I came across a funny vulnerability inside
OpenPAM (note that this is different from Linux-PAM)
as used in FreeBSD
a FreeBSD 8.1 machine. The bug is that a program,
namely kcheckpass, which is suid to root, is calling
pam_start() with a user provided argument which makes
the PAM stack parse user owned
config files which ends in loading of user
provided DSO's. WTF?!
Interestingly, OpenPAM recently introduced a filter for
the service name via
http://trac.des.no/openpam/changeset/478/trunk/lib/openpam_configure.c
commit but I dont think that any BSD or so vendor is
aware of it.
A really trivial PoC exploit can be found here.
[Update:] Solaris is not using OpenPAM (at least the OpenSolaris
version I checked), but I could not find code that strips
off certain character sequences. As the PAM setup is different
from the /etc/pam.d we know it is possible that there are no
consequences if the service argument is not filtered.
However a lot of BSD derivates
use OpenPAM and OSX as well. The question is whether one can
find a vector different than the kcheckpass which is usually
found with all KDE3 and KDE4 installs.
If you can confirm vulnerability on any Solaris or non-FreeBSD
machine, please let me know. Also if you found out how OSX
can be exploited this way.
Thursday, November 3, 2011
Fun with git-upload-pack
The android git was recently moved so I was eager to check
out the new sources. But I always got a 403! What was wrong?
Looking into some forums showed that lots of folks seems to
have the same problems so I post this in the hope that it
saves other developers some hours of debugging. At the end it seems
just to be an issue about the git version or git setup.
I cloned a repo with a clean, new machine and compared the
HTTP stream with what I got from a working box to find
out why some checkouts worked and some dont. Heres is the
old git pull:
and here is the new one with the diff marked green:
Somewhat surprising since according to the download page
git 1.6.4 should just be fine.
Now everything works smoothly. Not a very technical issue indeed,
but tracking down strange issues helps to stay keen. More than
just searching the web for a solution.
out the new sources. But I always got a 403! What was wrong?
Looking into some forums showed that lots of folks seems to
have the same problems so I post this in the hope that it
saves other developers some hours of debugging. At the end it seems
just to be an issue about the git version or git setup.
I cloned a repo with a clean, new machine and compared the
HTTP stream with what I got from a working box to find
out why some checkouts worked and some dont. Heres is the
old git pull:
and here is the new one with the diff marked green:
Somewhat surprising since according to the download page
git 1.6.4 should just be fine.
Now everything works smoothly. Not a very technical issue indeed,
but tracking down strange issues helps to stay keen. More than
just searching the web for a solution.
Friday, October 7, 2011
Friday, August 19, 2011
New sshttp available
I uploaded a new sshttp tarball to fix potential slowdown
for a special usage pattern where thousands of clients
without sending data upon connect would slow down
other users connections.
for a special usage pattern where thousands of clients
without sending data upon connect would slow down
other users connections.
Friday, August 5, 2011
refactored IPv6 load balancing software
In 2003 I attended a class at University about IPv6.
Students have had to choose a topic to work about and I
chose to write a load balancing software for IPv6
utilizing the netfilter QUEUE target. It was one of the first
available load balancers for IPv6 ever, long before the
LVS project implemented IPv6.
Since the old code was not the most performing one (even though
bandwidth and latency tests showed acceptable results) and
the underlying netfilter changes made it useless on new
Linux systems, I re-wrote it. It is now better performing,
is able to use multiple cores/SMP and runs as user.
Additionally the failover code for IPv4 has been improved
(it is able to balance IPv4 traffic too).
You can argue that, since it runs in userspace, it will
always perform badly. However if you have a site for testing
with enough traffic, I'd like to see results.
If I'd be a professor at University, I would just let one
of my students write a thesis about its performance and let
him do some measuring, but I am not. :)
My performance test on a 100MBit link showed no real impact
on either throughput or latency. GBit performance measuring
has to be done. Anyone?
The code with a guiding README can be found here.
In any case it sharpened my skills about IPv6 and its sisters
and that alone was really worth re-mangling the code.
Great tools are about to be born (Hi Marc:)
Students have had to choose a topic to work about and I
chose to write a load balancing software for IPv6
utilizing the netfilter QUEUE target. It was one of the first
available load balancers for IPv6 ever, long before the
LVS project implemented IPv6.
It has since then been shown on a lot of conferences and follow-up
classes.Since the old code was not the most performing one (even though
bandwidth and latency tests showed acceptable results) and
the underlying netfilter changes made it useless on new
Linux systems, I re-wrote it. It is now better performing,
is able to use multiple cores/SMP and runs as user.
Additionally the failover code for IPv4 has been improved
(it is able to balance IPv4 traffic too).
You can argue that, since it runs in userspace, it will
always perform badly. However if you have a site for testing
with enough traffic, I'd like to see results.
If I'd be a professor at University, I would just let one
of my students write a thesis about its performance and let
him do some measuring, but I am not. :)
My performance test on a 100MBit link showed no real impact
on either throughput or latency. GBit performance measuring
has to be done. Anyone?
The code with a guiding README can be found here.
In any case it sharpened my skills about IPv6 and its sisters
and that alone was really worth re-mangling the code.
Great tools are about to be born (Hi Marc:)
pwnies 2011
As you might know or not, me and Marius have been nominated for the pwnie awards 2011 in the category best server side bug.
The CVE-2011-0997 DHCP bug was really funny and easy to exploit and often found in enterprise and campus network setups.
Unfortunally we didnt win, and to my surprise even taviso didnt win this time.
So I am likely the only one who has just one pwnie while all
the real good guys have at least two!
Nevertheless, congrats to the winners. In particular I like
pipacs' Lifetime Achievement award and $0ny's mastering in failure.
They both really deserve it.
The CVE-2011-0997 DHCP bug was really funny and easy to exploit and often found in enterprise and campus network setups.
Unfortunally we didnt win, and to my surprise even taviso didnt win this time.
So I am likely the only one who has just one pwnie while all
the real good guys have at least two!
Nevertheless, congrats to the winners. In particular I like
pipacs' Lifetime Achievement award and $0ny's mastering in failure.
They both really deserve it.
Subscribe to:
Posts (Atom)