OpenSSH Removes SSHv1 Support http://undeadly.org/cgi?action=article&sid=20170501005206
@HalvarFlake @kwanre in the past few years I decided to go back and re-write my exploits once they are "good enough" because I want them to be more clean/accurate/readable, not just for others, but for myself.
I'll never forget the emails from a leaked email spool around ~2002 when the US Army said one of jduck's exploits was "the cleanest we had ever seen". And it was. ;-)
I suspect the reason why most exploit code is so messy to read is that while writing the exploit you're still figuring out the "architecture and language" of the thing you are attacking.
There are so many false starts, and so many false assumptions when you start.
A simple false assumption can start you down a wrong path for weeks... but often you can't easily verify that it is false before starting.
What do hackers do when they retire? Looking at my father: build real steam G-scale locomotives, obviously…
And then your son calls you to talk shop but, well, what a twist, I think I might have just re-employed him! A complicated laser optics problem turned up, he has a patent on some laser stuff so "who do you call? dadhacker!"
Hand him the problem and barely an hour later he is asking the nasty questions. Wow. I hope I am still that smart when I turn 70.
The #keyboard I'll show today is special in many ways. It follows the existing theme of non-latin legends (somewhat, as it has latin legends too), but it has its history bound to the LISP family of languages - another big favourite of mine.
Witouth further ado: the Space Cadet keyboard!
A crossbred algorithm for solving Boolean polynomial systems
Antoine Joux and Vanessa Vitse
We consider the problem of solving multivariate systems of Boolean polynomial equations: starting from a system of m polynomials of degree at most d in n variables, we want to find its solutions over \F2. Except for d=1, the problem is known to be NP-hard, and its hardness has been used to create public cryptosystems[...]
Too Simple to be UC-Secure: On the UC-Insecurity of the ``Simplest Protocol for Oblivious Transfer'' of Chou and Orlandi
Ziya Alper Genç et al.
In 2015, Chou and Orlandi presented an oblivious transfer protocol[...][of] extreme simplicity and high efficiency.[...]claimed that their protocol is UC-secure under dynamic corruptions, which is a very strong security guarantee. Unfortunately, in this work we point out a serious flaw in their security proof[...]
Notes on nilcharacters and their symbols
@saper Mailman runs by executing a script directly from a pipe in the alias file. This pipe mechanism has, in the past, been rife with security issues when sendmail ran as root and is now somewhat ameliorated by using a non-root user.
The slight issue is that you need to compile Mailman to use the correct user. Now, smtpd uses a different mechanism than Sendmail so the port now only really supports OpenSMTPd, the default MTA on OpenBSD.
The story of how I started using OpenBSD VMM despite it not being ready is purely physical: rack in the US, 2U available, 4 machines needed. 1U for a critical system, 1U for a host to two VMs…
@saper Oh, I am an old Sendmail hand, been using it since BSD was one and from Berkeley… I simply cannot figure out how to port my Sendmail configuration to smtpd, it is purely a matter of mental block for I am almost certain that there is feature-by-feature parity (OK, perhaps BITNET & UUCP support are missing…).
I do have one Mailman install on 5.9 using smtpd and my only gripe is that newaliases does not seem to load new lists w/o an smtpd restart. Is that what you see too?
Current OpenBSD task list:
* migrate all boxes (over 40) to (at least) 6.0,
* move the anti-virus/anti-spam entirely to spamd/clamd-milter w/ "good rulez" dropping amavisd-new,
* figure out how to get mailman working with Sendmail again post-5.8: this really bugs me, the mailman port uses smtpd only and I just can't grok the correct smtpd config which does my Sendmail magic. This is preventing a critical upgrade.
It is actually a huge endeavour, and the last point has been daunting.
@phessler yes, I was wondering if I had blatantly missed a config change from pre-6.1 to 6.1-current, like the kernel option name in vm.conf.
Nothing which cannot be partially alleviated by an rdate in cron at 5m intervals to an internal NTP source, for the time being. vio hanging the VM was far more critical to me :)
Having said this I'd like the possibility of starting a known VM from vmctl changing only the kernel for updates. Daft idea?
@phessler yes, it used to work fine and was stable in pre-6.0 snapshots but, of course, vio would hang after a while so the upgrade to post-6.1 with the fixes for that is more important. I am wondering if I am missing a sysctl or config to keep time in sync, at least back to what it was before.
the clockdrift is extreme, we're talking 12hrs for a 36hr uptime and ntpd cannot cope.
There is also a weird issue with assigning 4Gb of RAM to the VMs (not possible) and I haven't had the time to check if it is an issue with limits or something else.
Having said all of this the pace of advance is impressive and hopefully we can have stable Linux guests too (yeah…), so far Alpine Linux apparently works.
The OpenBSD VMM subsystem, while still very green, is actually beautifully simple to use and setup making bhyve with vm-bhyve almost "complicated to use".
The vm.conf file is embarrassingly simple to write and, well, "obvious" in its syntax. I have only tested OpenBSD VMs which "just work" with the exception that they only really become useful when running 6.1-current as 6.1 has vio issues (at least with my setup).
-current as of 27/4 sadly appears to have a clockdrift issue but o/w works…
New #Phrack paper feed: "VM escape - QEMU Case Study" by Mehdi Talbi & Paul Fariello: