Contributed by rueda on 2017-07-04 12:20:17 UTC
from the better-late-than-never or shut-up-and-code dept.
TL;DR - A modernised version of Undeadly is available for testing at <https://beta.undeadly.org/>.
Broken features of the current site have been fixed, removed, or replaced.
The new software supports - and, where appropriate, requires - HTTPS. Testing, contributions, and constructive feedback would be appreciated.
An effort to modernise the Undeadly software was initiated in response to the article Undeadly and HTTPS.
This has resulted in substantially reworked software which is now available for public testing.
Note that this is not the completely new system which is (arguably) needed.
Contributed by rueda on 2017-07-04 04:48:43 UTC
from the the-saga-continues dept.
The flak reports by Ted Unangst (tedu@) continue with part 624.
Contributed by pitrh on 2017-07-01 13:25:05 UTC
from the all tomorrows random gaps dept.
As you may have heard (and as was mentioned in an earlier article
), on recent OpenBSD
snapshots we have KARL, which means that the kernel is relinked so each
boot comes with a new kernel where all .o files are linked in random
order and with random offsets. Theo de Raadt summarized the status in a
message to the tech@ mailing list, subject kernel relinking
5 weeks ago at d2k17 I started work on randomized kernels. I've been
having conversations with other developers for nearly 5 years on the
topic... but never got off to a good start, probably because I was
trying to pawn the work off on others.
Contributed by brynet on 2017-07-01 12:54:03 UTC
from the de-fanging dept.
Theo de Raadt (deraadt@) provided some history on the insecurity of TIOCSTI [simulate typed input on terminal], with a proposal to disable it on OpenBSD:
[...] there's always been the risk
that a program manages to retain tty association beyond it's intended
lifetime, and then it can perform injections with TIOCSTI.
So I've always wanted to get rid of TIOCSTI. I consider it the most
dangerous tty ioctl. [...]
This appears related to a discussion thread that came up on
oss-security@, and how Linux has steadfast rejected proposals to remove
Theo has already committed his change to disable TIOCSTI, which now returns EIO [input/output error].
Due to risks known for decades, TIOCSTI now performs no action, and simply
returns EIO. The base system has been cleaned of TIOCSTI uses [...]
This was made possible by changes made to csh/mailx in base by Anton Lindqvist (anton@).
I (brynet@), also committed a change recently to ksh removing an unnecessary call.
Contributed by pitrh on 2017-06-29 16:39:59 UTC
from the of goats and pufferfish dept.
The OpenBSD presence at the just concluded BSDCan
was quite strong, and here is the first trip report, from Phillipp Buehler
Most overheard in Tokyo was "see you in Ottawaaaaah", so with
additional "personal item" being Groff I returned home to plan the trip
Dan was very helpful with getting all the preparations
(immigration handling), thanks for that. Before I could start, I had to
fix something: the handling of the goat. With a nicely created harness, I
could just hang it along my backpack.
Contributed by pitrh on 2017-06-29 09:39:23 UTC
from the forward me unlocked dept.
Our next report from the d2k17 hackathon comes from Martin Pieuchot, who writes:
Hackathons are generally good to start or finish something, at Starnberg
I managed to do both.
I came to unlock the forwarding path and thanks to the multiple reviews
from bluhm@, sashan@ and claudio@ it happened! It started as a boring
hackathon because I had to review and fix all the abuses of splnet() in
pseudo drivers but then it went very smoothly. I still haven't seen
a bug report about the unlock and Hrvoje Popovski even reported a 20%
forwarding performance increase.
Then I started discussing and planning the next big step with claudio@
and bluhm@. How to unlock the socket layer? Well it's happening!
During the hackathon Claudio sent some diffs to start unlocking pfkey
and routing sockets and since then I started working on TCP receive
In the meantime I had to commit my futex(2) based mutex and
implementations for our libpthread. This improves the
performance of threaded applications a lot, which means most of ports.
I also did some cleanups to help towards having MI mutex and kernel
lock implementations. This should allow all our archs to benefit
from the lock instrumentations visa@ and jmatthew@ are working on.
Finally I committed some ddb(4) cleanups, mostly CTF related.
Thanks to mpf@ and genua for organizing this hackathon!
Thanks for the report, Martin!
It is worth noting that most, if not all, of the code mentioned here is already doing good work in recent snapshots.
Contributed by rueda on 2017-06-28 07:49:16 UTC
from the ref-ac-to-ring dept.
Alexander Bluhm (bluhm@) wrote in with a hackathon report:
As usual hackathons are a great time to get things commited. All
the other developers are around, you can discuss ideas and get code
To move towards network input without big kernel lock, I have looked
at the protocol functions and refactored them. Especially IP-in-IP
input that is used for IPsec tunnel mode needed some love. I have
fixed several bugs and have a diff ready that avoids one additional
queuing of the packets. This work had to be coordinated with mpi@,
who removed the kernel big lock from the forwarding path.
Contributed by pitrh on 2017-06-22 06:55:25 UTC
from the just enough ROP to TRAP yourself dept.
You heard it here (or on tech@) first: Trapsleds are in, and it makes
OpenBSD even safer. Work done by Todd Mortimer and submitted to tech@ in
thread was later committed
by Theo de Raadt.
Todd's message to tech says,
I have attached a patch that converts NOP padding from the assembler
into INT3 padding on amd64. The idea is to remove potentially conveinent
NOP sleds from programs and libraries, which makes it harder for an
attacker to hit any ROP gadgets or other instructions after a NOP sled.
Contributed by rueda on 2017-06-13 02:52:37 UTC
from the Charlemagne dept.
message to the tech@ mailing list,
Theo de Raadt (deraadt@) has announced a new randomization feature for
Over the last three weeks I've been working on a new randomization
feature which will protect the kernel.
Recently I moved all our kernels to a new mapping model, with patrick
and visa taking care of two platforms.
As a result, every new kernel is unique. The relative offsets between
functions and data are unique.
However, snapshots of -current contain a futher change, which I
worked on with Robert Peichaer (rpe@):
That change is scaffolding to ensure you boot a newly-linked kernel
upon every reboot.[...]
Read the full message
for the juicy details.
Note that, because of the new mechanisms, unhibernate does not work on
-current (for now).