About

This is where I put all the things I've created which I hope may somehow be useful to others.


Statement

I believe in modular, purpose-built software. The more freely a program or library can be adapted and joined to other software the better. This of course begs the question of interoperability, documentation and cooperation amongst developers, and is why I am a sharp proponent of free software. I cannot stress how important it is, not simply just for myself (in that regard I find it to be an unparalleled educational tool), but rather for humanity as a whole. It is the actualization of creating software without constraints of intellectual ownership/micromanagement.

I have a strong interest in distributed software systems, especially favoring self-healing networks and distributed data structures and associated techniques. Beyond that I prefer to create purpose-built, practical use applications in a variety of languages. Practical in that their sole use isn't to pad a resume, but rather be of some use to others now and in the future beyond direct use even, either for design ideas or coding practices. Being able to riddle off a list of intangibles for the sole purpose of creating a list reeks of convenience, if nothing else. Above all else, I would hope what I have created can be of some use to people, even if only pedagogical.

In retrospect, I have since come to understand that I am a very design-driven developer, perhaps even over designing at times. A vast majority of my effort is prepaid out beforehand designing multiple approaches and ideas. Generally this pays off since perfect information about the task at hand rarely exists (so much for SCRUM), and I'd rather fall back on a secondary design than have to re-design again on the fly. Over-designing also helps the implementation in terms of knowing what you'll expect out of certain parts of the program. Despite modern languages offering an over-abundance of higher-order constructs, I honestly don't believe in their liberal use, ie. Php's magic methods. Most of the highly extrapolated capabilities of modern languages are more reliably implemented by means of lower level controls. Illustratively, one could implement an alternative, and more highly-tailored form of reflection in any language that doesn't support it by means of status accessor methods. Judgment calls will inescapably need to be made about any design decision and in some cases these constructs can be indispensable, however a rush to be highly reflexive/dynamic isn't always the best approach, as readability can suffer.



regreSSHion
Aug 13, 2024

regreSSHion

CVE-2024-6387

Heres the skinny on this summer-dog-days fun RCE.

OpenSSH Version History

• [START - 4.4p1)     VULNERABLE
• [4.4p1 - 8.5p1)     FIXED   patched in CVE-2006-5051 and CVE-2008-4109
• [8.5p1 - 9.8p1)     VULNERABLE  (again)

However,
This is basically a nothingburger.
The bug was re-introduced in ~2022-ish in Openssh version 8.5p1. It has a POC against 32bit systems, running this daemon.
Meanwhile 64 bit systems are unaffected due to layout space randomization, yadda....

--> In the year of our lord 2024 very few systems, if any, are on 32 bit x86 with Openssh. <--

I just checked my fleet as well. The only likely 32-bit candidates are ARM/MIPS for routers, and guess what they run, dropbear.

I mean, check yours, but mine were OpenWRT and DietPI, both using dropbear.

Armbian does use OpenSSH though the variants i have are all 64, not saying its pure, but rather anecdotal.

Realistically,
Raspbian is the only common SOC distro which, if it was deployed with 32 bit could be problematic.
Again, you'd have to have deployed it in the last year or two AND not have the 64 bit version.
Its thankfully not a situation I found myself in but from what I read, the 32 is still a widely used variant, if not THE variant.
The above is the most common candidate for a vulnerable device.

In x64 land, typical systems just dont fall into the 32bit category at this stage in the game, those systems are outliers.
However, definitely update your herd, even if you are completely 64bit, but there is a case to not kneejerk since there is a huge, non-vulnerable version gap (4.4-8.5) which is quite fine to leave in service(Terrapin Attack CVE-2023-48795 not withstanding), and while the last few years have been vulnerable, if you haven't deployed many Raspberry-PI like systems in that window you're also not most likely at risk.

# query your daemon
$ nc -v -v <host> <sshport>

# what system your're running
$ uname -m