Jupiter Broadcasting

Diving for BSD Perls | BSD Now 142

This week on the show, we have all the latest news and stories! Plus an interview with BSD developer Alfred Perlstein, that you won’t want to miss. Sit tight, the show starts now on your place to B…SD!

Thanks to:





Direct Download:

Video | HD Video | MP3 Audio | OGG Audio | Torrent | YouTube

RSS Feeds:

MP3 Feed | OGG Feed | iTunes Feed | Video Feed | HD Vid Feed | HD Torrent Feed

Become a supporter on Patreon:

– Show Notes: –

Headlines

The May issus of BSDMag is now out


A rundown of the FPT_W^X_EXT.1 security reqiurement for General Purpose Operating Systems by the NSA


DistroWatch reviews new features in FreeBSD 10.3


BSD Unix: Power to the people, from the code

“But too much focus on Joy, a favorite target for business magazine hagiography, obscures the larger picture. Berkeley’s most important contribution was not software; it was the way Berkeley created software. At Berkeley, a small core group — never more than four people at any one time — coordinated the contributions of an ever-growing network of far-flung, mostly volunteer programmers into progressive releases of steadily improving software. In so doing, they codified a template for what is now referred to as the “open-source software development methodology.” Put more simply, the Berkeley hackers set up a system for creating free software.”

“BSD patriots argue that the battle is far from over, that BSD is technically superior and will therefore win in the end. That’s for the future to determine. What’s indisputable is BSD’s contribution in the past. Even if, by 1975, Berkeley’s Free Speech Movement was a relic belonging to a fast-fading generation, on the fourth floor of Evans Hall, where Joy shared an office, the free-software movement was just beginning.”


iXsystems

Interview – Alfred Perlstein – alfred@freebsd.org / @splbio


News Roundup

.NET framework ported to NetBSD


OpenBSD SROP mitigation – call for testing

“We describe Sigreturn Oriented Programming (SROP), a novel technique for exploits and backdoors in UNIX-like systems. Like return-oriented programming (ROP), sigreturn oriented programming constructs what is known as a ‘weird machine’ that can be programmed by attackers to change the behavior of a process. To program the machine, attackers set up fake signal frames and initiate returns from signals that the kernel never really delivered. This is possible, because UNIX stores signal frames on the process’ stack.”

“Sigreturn oriented programming is interesting for attackers, OS developers and academics. For attackers, the technique is very versatile, with pre-conditions that are different from those of existing exploitation techniques like ROP. Moreover, unlike ROP, sigreturn oriented programming programs are portable. For OS developers, the technique presents a problem that has been present in one of the two main operating system families from its inception, while the fixes (which we also present) are non-trivial. From a more academic viewpoint, it is also interesting because we show that sigreturn oriented programming is Turing complete.”

“Utilizing a trick from kbind(2), the kernel now only accepts signal returns from the PC address of the sigreturn(2) syscall in the signal trampoline. Since the signal trampoline page is randomized placed per process, it is only known by directly returning from a signal handler.”

“As well, the sigcontext provided to sigreturn(2) now contains a magic cookie constructed from a per-process cookie XOR’d against the address of the signal context.”


Running Tor in a NetBSD rump unikernel


An update on SSH protocol 1 (“we’re most of the way towards fully deprecating SSH protocol 1”

“We’ve had this old protocol in various stages of deprecation for almost 10 years and it has been compile-time disabled for about a year.
Downstream vendors, to their credit, have included this change in recent OS releases by shipping OpenSSH packages that disable protocol 1 by default and/or offering separate, non-default packages to enable it.

This seems to have proceeded far more smoothly than even my most optimistic hopes, so this gives us greater confidence that we can complete the removal of protocol 1 soon. We want to do this partly to hasten the demise of this cryptographic trainwreck, but also because doing so removes a lot of legacy code from OpenSSH that inflates our attack surface. Having it gone will make our jobs quite a bit easier as we maintain and refactor.”


Beastie Bits


Feedback/Questions