Monday, December 12, 2016

Tales of spoofing on BSD based kernels (actually Darwin).Although OSX setups should mostly be targets of spoofedpackets, there are times when you need to spoof IPv6 packetsfrom a OSX box.Unlike with IPv4, there is no such thing as a IP_HDRINCLsocket option that lets you pass arbitrary IP headersto raw sockets. In fact, there are RFCs on the subject(RFC3542 and RFC 3493) and the authors put a lot of effortto specify on how certain flags and details may be modified,but the end of the story is that, in this way or another,its not possible to have a handy library function togenerically send a spoofed IPv6 packet on a raw socket on OSX.man 4 ip6 says:"Note: Since the checksum is always calculated by the kernel for an ICMPv6 socket, applications are not able to generate ICMPv6 packets with incorrect checksums (presumably for testing purposes) using this API."I like the presumably for testing purposes part most.So I had to eventually switch to packet sockets formy UDP6 sample of libusi++. Its a bit more work toset it up initially, but after that all the get/setof source addresses etc. work as expected.

Thanks to the inject function of libpcap, thats easyenough.Its probably not worth the effort to handle all thesocket options or ancillary data for raw IPv6 sockets just to achieve a goal that at the end still has some header-parts un-modifiable.I did not test it on OpenBSD or FreeBSD, but the manpagereads more or less the same, so I expect the same problemexists there too.

Thursday, August 18, 2016

Once again, opmsg is ahead of the curve, by introducingwhat I will call cross-domain ECDH kex.The idea behind it is straight forward and obvious,so that I wouldn't claim to be the first who invented it.Digging the interweb a bit, didnt show quick results,so I named it cross-domain ECDH without walking to thelibrary to do more in-depth research about someone elsehaving different names for it. If there is, feel freeto point me to it.ECDH is a neat way to do your Key Exchange (Kex). It hassmall footprint in speed and size. Its even fast enoughto be done multiple times in a row, without the user reallynoticing a slowdown. The drawback of ECDH is that the so calleddomain parameters for the curves are chosen by an entitythat you have to trust. Trust by means of: Nobody in thecommittee responsible for choosing the parameters wouldintroduce so called Nobody-But-Us (NOBUS) bits, thatwould weaken the resulting ECDH Kex secret.There are different ways to put trust into the domainparameters, like using some kind of sane and "well-known"seedings and algorithms to generate "reproducable" parameters(like Brainpool is doing). Other curve designers don't mind aboutit at all and resemble eat-or-die mentality. This leadsto some kind of flame-war and bashing between the differentcults of ECC evangelists. Nobody knows anything about the NOBUS,but everyone believes the opposite curve has backdoored parameters.opmsg puts an end to this war, by allowing users tospecify more than one curve to do the Kex with. Upto three curves may be specified. The master secret is derivedfrom the multiple distinct ECDH Kex's which are made. The idea is that in case there are NOBUS backdoors - even within every single curve -the different backdooring parties would not work togetherand share their NOBUS knowledge to each other. They wontshare their knowledge, because a potential NOBUS insidea NIST curve would be the holy grail that they are neverever show to someone else, and in particular not to theparty who, lets say, put their NOBUS into the GOST curves.So, even if each curve that you chose to do your ECDH Kexwould be weak, the overall cross-domain ECDH Kex is secure.As long as you really choose your curves cross-domain, e.g.not three of the NIST curves in a row.This feature is experimental. Please refer to the chapterin the README which explains the particular config options.If you are not in this curve flame war, you don't need tochange anything at all. Its all in the compatibility-mixand you can just as work as before, if you prefer.

Thursday, July 7, 2016

A new tool (opcoin) has been added to opmsg's contrib directory,which allows to convert bitcoin keys to opmsg personas.You may find convertable public BTC keys in anyBTC (P2PKH) transaction. So you just go to your favoriteblockchain website and search for an address that you knowbelongs to a certain person and import their pubkey(s).The calculated BTC address (match) ensures that its reallythe key you want to import and will since then appearas the personas name inside opmsg keystore.Voila! Suddenly opmsg became the crypto system with the largestkeybase world wide! One more benefit: you can ensure that adedicated persona name is in possession of a private key,by authenticating them via micro transactions.Read more details here.

Thursday, June 23, 2016

This week I published a PoC for CVE-2016-4989 , which isyet another local root exploit for setroubleshoot, workingout of the box on CentOS/RHEL 6.6, 6.7, 6.8, 7.0 and 7.1.The underlying vulnerability and exploitation strategyis very similar to CVE-2015-1815. So the writeup insidethe git almost entirely applies, except that the PoCmay be executed via remote shells (ssh) and that it isusing a helper binary in order to get a SELinux domainconfinement for an unconfined user, triggering the buginside setroubleshoot. To my knowledge this is a novelapproach. Its also new that straight-shooter may beused as a Docker breakout, if run inside a container,which has running setroubleshoot running on the host.Out of personal interest: If you like exploits - eitherprofessional, or as a hobby - and demand forfreedom of speech or freedom of expression, try your bestto lobby against the Wassenaar regulation of exploits. TheWassenaar regulation of exploits is just a vehicle (sold toyou as a privacy win) to cover backdoors and criminalizebug finding. Any serious exploit coder and researcher I knowis arguing against Wassenaar, and so should you.

Friday, May 6, 2016

... and a lot of hassle checking out the new OpenSSL 1.1.0 APISupport for chacha20-poly1305 stream cipher with AAD (poly1305)thats causing erection to so many cryptographers recentlyhas been added to opmsg.Its only available to > OpenSSL 1.1.0,so be sure your peer is also using it when you sendop messages like that.The more tricky part is the new API that comes withOpenSSL 1.1.0. Despite fixing a lot of issues in theirTLS implementation, the OpenSSL project still seems tohave enough time breaking their own API by:1. Making structures opaque, whichmeans you cant longer declare EVP_MD_CTX and other types on the stack. So you are forced to use EVP_MD_CTX_create()/EVP_MD_CTX_destroy() since the type is forward declared now.2. At the same time, removing the EVP_MD_CTX_destroy() function and adding _new()/_free() functions which do the same (!).

3. Declaring macros for EVP_MD_CTX_destroy(xxx) (with braces!) so that unique_ptr<> deleters eventually also break. 1-3. alltogether make sure that no matter how you declared your variables, the OpenSSL team decided to throw your code to trash.4. As if this isnt enough, EVP_PKEY_type() has been removed, even if its usage has been encouraged by various code examples in their manpage.So OpenSSL decided to open a wiki to track the amount ofopen source projects they offended by causing quite goodamount of time thats needed to rework the code.Theres definitely more to be added there in future.Nevertheless, opmsg is now OpenSSL 1.1.0 ready and stillworks fine with lower versions and LibreSSL.If its possible for you, you should consider switching toLibreSSL , as everything is more smooth and straight there.(But I think LibreSSL project should also offer https:// :)

Thursday, April 28, 2016

Whenever you are tempted to type gpg, you should typeopmux since now().I recently pushed opmux to the git that allows for easyuse of opmsg and gpg in parallel and to seamless integrateinto your MUA by just pointing the gpg-path to the opmuxbinary and adding keyid-format long to your gpg configfile.Since then, opmux will transparently choose the rightbinary for decryption, based on message markers usedby either world. On encryption, in whatever world thekey-id is found, it is passed along to it. If no key-idis found, both pubkey databases are shown so the usercan select one. Be sure to nevertheless have a lookat the opmux part of the README.md file.Here are some Enigmail screenshots on sending, decryptionand debug console:

Tuesday, March 8, 2016

This time we trick sshttp into utilizing thesplice(2) syscall to achieve zero-copy of thenetwork data thats muxed across the sockets.If you want to give it a try, pull sshttp gitand checkout the splice branch. Everything elsegoes the same.Using splice() instead of read()/write() insidethe core loop has a performance benefit. In the idealcase (SPLICE_F_MOVE is honored by kernel), insteadof copying megabytes of data, the PTE's inside the kernelare just set up to point to the internal pipe buffers.sshttp may still run at 100% CPU (which is perfectly OKwhen downloading huge files) but has more throughput at thesame time. Below is a screenshot of a parallel downloadof a 5MB file (per 30 http clients) and a strace showingthe splicing thats happening inside, which is basicallya poll/splice loop.

Friday, January 29, 2016

Refactored my libusipp packet framework's receivingfunctions (sending will be optimized later) to:o Reflect new libpcap API, in particular things changed about selectable fd's and immediate mode. It works best if you just pull & build libpcap, as most distros and OSX may have outdated libpcaps installed (you will notice by missing symbols)o refactoring sniffpack() functions to not longer rely on dynamically allocated memory but using fix buffers and offsets to handle incoming packets (much) faster. The new[]/delete[] memory allocation was a hangover from the 90's when I initially didn't build it with QUANTUM in mind.o Implementing RX classes for string and fd receiving (tuntap support)o Adding support to allow sniffing from file:// devices to debug via wireshark packet captures later on.o support QoS data on wifi linksSome things in libpcap still suck, for instance the timeoutfunction doesn't accept stuct timeval and cannot be called oncea capture handle has been activated. This forces me tokeep my own timeout functionality which is sub-optimal.As usual, be warned about API changes in libusi++: I add/changewhatever I feel is needed there. API stability is not mymain goal.Happy QUANTUM your IoT! :p