Conversation

Notices

1. Embed this notice
   Sexy Moon (moon@shitposter.club)'s status on Wednesday, 21-Sep-2022 23:20:23 JST Sexy Moon
   another exchange lost 200 mil because they got hit with a recent exploit that can find the private key of weak "novelty" addresses with leading zeros.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:20:19 JST Hélène

     in reply to
     @Moon I mean why would anyone make their public keys purposefully smaller for such purposes
     
     wonder what the exploit is though
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Wednesday, 21-Sep-2022 23:21:36 JST Sexy Moon

     in reply to

     • Hélène
     @helene i'll try to find it.
     Hélène likes this.
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Wednesday, 21-Sep-2022 23:25:12 JST Sexy Moon

     in reply to

     • Hélène
     @helene https://blog.1inch.io/a-vulnerability-disclosed-in-profanity-an-ethereum-vanity-address-tool-68ed7455fc8c
     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:25:15 JST Hélène

     in reply to
     @Moon ah, a PRNG failure
     even worse, that's really bad
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:25:50 JST Hélène

     in reply to

     • narcolepsy and alcoholism :flag:
     @hj @Moon and i thought Pleroma was a gnostic concept...
   • Embed this notice
     narcolepsy and alcoholism :flag: (hj@shigusegubu.club)'s status on Wednesday, 21-Sep-2022 23:25:51 JST narcolepsy and alcoholism :flag:

     in reply to

     • Hélène
     @Moon @helene i thought Profanity was an XMPP client...
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Wednesday, 21-Sep-2022 23:26:26 JST Sexy Moon

     in reply to

     • Hélène
     @helene people do novelty addresses for tor hidden services too, it's just stupid imo.
     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:27:33 JST Hélène

     in reply to
     @Moon it's not that stupid because it's a small "proof of work" and depending on the length of the vanity part + time needed, it helps against phishing and a few other things
     
     at least, on tor
     it doesn't have to be unsafe at all, just has to be done right
   • Embed this notice
     narcolepsy and alcoholism :flag: (hj@shigusegubu.club)'s status on Wednesday, 21-Sep-2022 23:27:38 JST narcolepsy and alcoholism :flag:

     in reply to

     • Hélène
     @helene @Moon at least PleromaFE is unambigious
     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:28:25 JST Hélène

     in reply to

     • chjara
     @chjara @Moon they actually aren't less secure
   • Embed this notice
     chjara (chjara@snowdin.town)'s status on Wednesday, 21-Sep-2022 23:28:30 JST chjara

     in reply to
     @Moon for some reason i never really thought about how vanity addresses are insecure since they lower the search space
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:31:10 JST Hélène

     in reply to
     @Moon take it this way: we could say any part of what an address starts with is actually vanity
     
     it doesn't make a difference on the search space, it's just that it differs on generation because you're generating random private keys until you get a public key that satisfies what you're looking for (the vanity parts) which is... basically partial bruteforce on a public key which you don't really know
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Wednesday, 21-Sep-2022 23:31:15 JST feld

     in reply to

     • Hélène
     > PRNG failure
     
     this is one of my nightmares and why I refuse to trust anything except FreeBSD for my own stuff... it has really good PRNG design
     Hélène likes this.
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Wednesday, 21-Sep-2022 23:31:23 JST Sexy Moon

     in reply to

     • Hélène
     @helene I will take your word for it since I am not good with math. My intuition just suggested that if you're crunching to get a particular result then the crunching to reverse it would be less difficult.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:32:38 JST Hélène

     in reply to

     • feld
     @feld @Moon i wouldn't trust FreeBSD when it comes to security honestly, but it's on a case-by-case basis I'd say
     OpenBSD most certainly does it right but the PRNG depends on what you're trying to achieve
     using strong digest algorithms and ciphers is almost always a good prng source
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Wednesday, 21-Sep-2022 23:37:27 JST feld

     in reply to

     • Hélène
     A few of the security guys on FreeBSD's team work/have worked in malware research and just laugh at OpenBSD because the stuff they implement is bypassed by modern malware all the time, so I don't worry too much
     
     The bleeding edge security research in *nix land is happening by some FreeBSD devs and it's called CHERI. This is the real solution. Not rewriting everything in Rust. Not implementing all the performance killing nonsense that OpenBSD implements. (And FreeBSD's Capsicum is better than OpenBSD's Pledge; Pledge is just easier to use)
     
     But honestly. CHERI is the future. That's how we solve the problems that plague us.
     
     https://papers.freebsd.org/2019/bsdcan/davis-cheriabi/
     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:42:48 JST Hélène

     in reply to

     • feld
     @feld @Moon oh i've heard about cheri but never looked into it
     
     most reasons i don't trust freebsd is because of the kind of kernel exploits popping out of it fairly frequently since PS4 release (of course, since it runs FreeBSD) and even a bit before that; as well as the overall attack surface and the kernel design (but then again; what else to expect on monolithic kernels)
     
     i should try looking into it, not that i think OpenBSD design is the best for security anyway (it's still a *nix and a monolithic kernel, after all) but they do tend to have safer practices when it comes to their code; though they indeed do not research or protect on the hardware side of attacks
     
     it is also likely that openbsd is just less looked at, anyway
   • Embed this notice
     i seethe and (cope@eeeeeeeee.eu)'s status on Wednesday, 21-Sep-2022 23:42:52 JST i seethe and

     in reply to

     • Hélène
     @helene yeah the real problem here is the "deterministically" part of the article
     real vanity generators like https://github.com/cathugger/mkp224o are purely probabilistic
     8 chars of vanity is saving an attacker about 1 day of computation on a search space of some hundred millennia
     Hélène likes this.
   • Embed this notice
     Johnny Peligro (mischievoustomato@varishangout.net)'s status on Wednesday, 21-Sep-2022 23:43:34 JST Johnny Peligro

     in reply to

     • Hélène
     • feld
     @feld @helene @Moon interesting! man i wish freebsd had better hw support. time to spin a vm
     Hélène likes this.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Wednesday, 21-Sep-2022 23:46:04 JST feld

     in reply to

     • Hélène
     tbh some of those kernel exploits found in PS4 (which was FreeBSD 9.0-ish, btw) were fucking wild and it's really just a testament to how good that person is finding obscure vulnerabilities than anything else, really.
     Hélène likes this.
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Wednesday, 21-Sep-2022 23:46:36 JST Sexy Moon

     in reply to

     • Hélène
     • feld
     @feld @helene pledge and capsicum are not that comparable. pledge is just a syscall or something that drops privileges when you call it so it's easy to do in a C program. openbsd refuses to implement capabilities or mandatory access controls because they believe in practice they are too complicated and therefore used incorrectly. I have mixed feelings about that assertion.
     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:47:14 JST Hélène

     in reply to

     • feld
     @Moon @feld yeah, it's not good design honestly
     you should be spawning with restricted privileges and not descalating, agreed
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:48:31 JST Hélène

     in reply to

     • feld
     @feld @Moon PS5 kexploits are newer FreeBSD iirc but I didn't consider them that wild; but I might just be quite biased from experience with other hardware
     though the guy is indeed very good, not surprising from a Project Zero hire after all
   • Embed this notice
     Jim (sullybiker@sully.site)'s status on Wednesday, 21-Sep-2022 23:48:51 JST Jim

     in reply to

     • Hélène
     • feld

     @feld @helene @Moon Interesting read.

     Hélène likes this.
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Wednesday, 21-Sep-2022 23:48:55 JST Sexy Moon

     in reply to

     • Hélène
     • feld
     @helene @feld openbsd's most of openbsd's claim to security is based on "correctness" and "simplicity", it's up to the individual to decide if they think that is a valid way of looking at it.
     Hélène likes this.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Wednesday, 21-Sep-2022 23:49:04 JST feld

     in reply to

     • Hélène
     This is true. They achieve similar goals but very very differently.
     
     Also FreeBSD has the MAC framework which you can do amazing things with if you want. Historically a lot of custom vendor appliances/solutions relied on it to extend security/hardening of their system. Like you can do stuff like require every binary the system match a known checksum before executing it and it's all done very fast in kernel
     Hélène likes this.
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Wednesday, 21-Sep-2022 23:54:06 JST Sexy Moon

     in reply to

     • Hélène
     • feld
     @feld @helene personally i am a fan of mandatory access controls, in theory. in practice, apparmor is a leaky sieve and selinux is very confusing. freebsd could be a lot better but i'm not going to abandon linux for it.
     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Wednesday, 21-Sep-2022 23:58:43 JST Hélène

     in reply to

     • inference
     • feld
     @feld @inference @Moon ASLR can help against a handful of exploits and usually requires a way to bypass it (ROPchains basically stop working if the code is ASLR'd, so you need a leak + a way to generate the ROPchain after that leak, which usually implies Turing completeness is needed to do math and prepare the exploit, etc)
     fake vtables end up suffering from the same problem, heap funnies become a real pain, UAFs are less powerful on their own, etc...
     it's really not a useless mitigation, but it really has to be done right, and it almost never is because there's almost always a range of predictable or statically adressed memory on Unix/Win32 systems; they weren't designed with that in mind from the ground up and they prefer to keep backwards compatibility
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Wednesday, 21-Sep-2022 23:58:44 JST feld

     in reply to

     • Hélène
     • Hyolobrikator
     • inference
     ASLR isn't actually good security mechanism. It's been effortlessly bypassed by Windows malware since XP, so why do we care so much about implementing it on new systems when the attackers have very good methodologies to defeat it already? It adds a lot of complexity to the kernel that will be hard to revert in the future when it's properly solved in hardware (CHERI).
     
     The only reason FreeBSD is implementing their limited version is because there are some LLVM features I can't recall the name of that can produce some pretty hardened binaries but it requires some ASLR-ish kernel support
     Hélène likes this.
   • Embed this notice
     inference (inference@plr.inferencium.net)'s status on Wednesday, 21-Sep-2022 23:58:48 JST inference

     in reply to

     • Hélène
     • Hyolobrikator
     • feld
     @Hyolobrika @feld @helene @Moon If this is true, it's a huge change for FreeBSD. FreeBSD security is pathetic in its current form. It even allows ASLR bypass by disabling itself after 4 failed brute forcing attempts, and even allows disabling ASLR via an API. What a joke.
     
     Not to mention the lack of almost every modern security feature in existence.
   • Embed this notice
     Hyolobrikator (hyolobrika@gleasonator.com)'s status on Wednesday, 21-Sep-2022 23:58:49 JST Hyolobrikator

     in reply to

     • Hélène
     • inference
     • feld
     cc: @inference
     thoughts?
   • Embed this notice
     just an actual husbear (guizzy@pleroma.guizzyordi.info)'s status on Wednesday, 21-Sep-2022 23:59:01 JST just an actual husbear

     in reply to

     • Hélène
     • feld
     @Moon @feld @helene It used to be that a large amount of software documentation would just tell you to disable selinux to install their software because they would rather do that than learn and document how to work with it. It got better though.
     Hélène likes this.
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Thursday, 22-Sep-2022 00:01:54 JST Sexy Moon

     in reply to

     • Hélène
     • Hyolobrikator
     • inference
     • feld
     @feld @Hyolobrika @helene @inference ASLR broke binary compatibility of old software (the ultimate no-no in the windows world) and they had to nerf it to get even partial compatibility with vista-onwards circa 2007.
     Hélène likes this.
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Thursday, 22-Sep-2022 00:02:25 JST Sexy Moon

     in reply to

     • Hélène
     • just an actual husbear
     • feld
     @guizzy @feld @helene it's worse than that, sometimes they don't want you to use it because they know exactly how leaky their program is and releasing a complicated selinux profile for it would be embarrassing because it would document everything it touched.
     Hélène likes this.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Thursday, 22-Sep-2022 00:04:45 JST feld

     in reply to

     • Hélène
     • Hyolobrikator
     • inference
     Indeed, they're very disruptive changes.
     
     These things are the definition of technical debt tbh. I would not want to be responsible for the codebase when all of these extremely complex kernel changes are officially useless legacy junk
     Hélène likes this.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Thursday, 22-Sep-2022 00:08:26 JST feld

     in reply to

     • Hélène
     • inference
     that's why if you need a truly hardened *nix system you reach for HardenedBSD, not OpenBSD. OpenBSD has a much inferior ASLR implementation (HBSD: 41 bits, OpenBSD: 32 bits)
     Hélène likes this.
   • Embed this notice
     Hélène (helene@p.helene.moe)'s status on Thursday, 22-Sep-2022 00:09:39 JST Hélène

     in reply to

     • inference
     • feld
     @feld @inference @Moon the number of bits for ASLR'ing the address space isn't an issue above a certain amount (like even 20bits) as long as you make it so that access faults aren't recoverable at all
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Thursday, 22-Sep-2022 00:14:46 JST Sexy Moon

     in reply to

     • Hélène
     • inference
     • feld
     @helene @feld @inference oh i found the explanation of how my rng works:
     Hélène likes this.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Thursday, 22-Sep-2022 01:17:12 JST feld

     in reply to

     • Hélène
     • inference
     I wish I could tag Shawn in this thread because he's brilliant and knows far more about this than I do. (also I worked with him @ Cisco/Talos/Sourcefire -- he was in malware research, I was part of engineering the malware research environment. Which even for Windows malware is running on FreeBSD btw hehe)
     Hélène likes this.
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Thursday, 22-Sep-2022 01:17:21 JST Sexy Moon

     in reply to

     • Hélène
     • inference
     • feld
     @feld @helene @inference I'm still using haveged with it. it is much faster than other methods
     Hélène likes this.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Thursday, 22-Sep-2022 01:17:22 JST feld

     in reply to

     • Hélène
     • inference
     Do you actually use one of those? I've had conversations with kernel devs who have told me to keep away as they're junk because they just can't beat mixed entropy pools
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Thursday, 22-Sep-2022 01:17:45 JST feld

     in reply to

     • Hélène
     • inference
     yep. I know Shawn of HBSD, and was an early supporter. I'm still mad about the way he was treated by some of the FBSD core devs. If you're going to go down this rabbit hole, HBSD is the correct solution. I understand FBSD's resistance now, though, when before I was just angry they appeared to be lazy and careless. Instead, they were just being patient and waiting for the correct solution.
     
     It helps if you think of FreeBSD as not so much an end-user solution but also a research project and partially designed as a build-your-own-OS/appliance toolkit which is kind of the place it fills anyway. There are a lot of things not enabled/configured by default which is annoying, but you just have to bring your own default configuration with you.
     
     Now that I see CHERI is on the horizon and RISC (ARM/RISC-V) is most definitely our future, I don't worry so much.
     
     I'm also willing to bet Apple is one of the first mass market implementors of CHERI. They will definitely leverage it in future CPUs. It only makes sense -- they have their own compiler, their own kernel, and their own CPUs. Should be super easy to pivot to.
     Hélène likes this.
   • Embed this notice
     inference (inference@plr.inferencium.net)'s status on Thursday, 22-Sep-2022 01:17:46 JST inference

     in reply to

     • Hélène
     • feld
     @feld @helene @Moon I can agree that HardenedBSD is much more secure than OpenBSD. I recently posted why OpenBSD isn't as secure as people think it is. It doesn't even use CFI.
     
     https://hardenedbsd.org/content/easy-feature-comparison