haha wouldn't it be cool if you learned C and assembly haha lowlevel.academy

@AWIRE_onpc

Ай бұрын

no it wouldnt

@PrinceKumar-yo9lr

Ай бұрын

Bro can you please tell me how much time it takes to learn assembly language from which you can write your own script exploits and malwares and ransomwares. And which are the best high level languages which are used to write a malware or ransomwares

@linuxnoodle8682

Ай бұрын

no it wouldnt

@cerulity32k

Ай бұрын

​@@PrinceKumar-yo9lr It really depends on what you're exploiting. If it's a local vulnerability (one through the operating system) then you'll need to have full control over the arguments you pass to the operating system's APIs. This is best done with a low level language such as C, C++, Zig, or even Rust. If you need *really* fine control, you can use Assembly, but it's not common. However, must vulnerabilities are rooted in networking. These can be made in any language that has networking capabilities. Rust is my pick, just because of how easy it is to throw some bytes through a socket. POSIX's C sockets take a bit more work to set up than a higher-level TCP stream, but it's way better than Winsock from what I've seen. However, this all assumes you have a vulnerability to exploit. Vulnerabilities are often patched as soon as they pop up. Something way cooler than just malicious stuff is "fun" malware, which was away more prevalent back then. It didn't usually do anything super serious, but it would take control of the system and show you something really cool looking. There are some Windows 10 programs that do this with WinGDI (see MEMZ and Chloroform). You could learn to do the same, since it looks really cool. You don't need to exploit anything to make something really cool, just look at Furnace.

@HowDoYouUseSpaceBar

Ай бұрын

@@PrinceKumar-yo9lr 2 minutes and 34 seconds 👍

Temple OS is once again not affected? Coincidence?

@lukeumhoefer

Ай бұрын

Too holy to get hacked 🙏

@starling000

Ай бұрын

Not a coincidence.

@dashdashdash_

Ай бұрын

kowinkydink?

@theghost9362

Ай бұрын

it's GOD'S work my dude

@rishil6491

Ай бұрын

Thats why god uses it

That's why we call it "OpenSSH".

@JoelTutka

Ай бұрын

no cap

@AkivaB

Ай бұрын

I still don't get why people open the SSH port when they can use wireguard since if the device is compromised all bets are off anyway

@glitchy_weasel

Ай бұрын

​@@AkivaB Guess it's difficult to maintain the wireguard configuration for all your devices, especially for multiple users - personally I like to use an open source mesh VPN like Tailscale or ZeroTier.

@GorgioFernen

Ай бұрын

the door is wide open

@Drudge.Miller

Ай бұрын

😂

The creativity of threat hunters will NEVER cease to amaze me

@brainites

Ай бұрын

Breakers are one or several steps ahead of builders.

@Kane0123

Ай бұрын

Agreed. People doing this kind of work are fascinating and awesome

@mcpr5971

Ай бұрын

There has to be an invisible hand from the intelligence community to plant some of these. I'm not saying that programmers never make mistakes that allow sploits, but those are probably the exception, not the rule.

@HesderOleh

29 күн бұрын

@@brainites by definition, or they wouldn't be breakers. Sometimes builders can be ahead, as is the case with attempts at quantum computer proof crypto that is being worked on before quantum supremacy is reached.

@davebakker1748

25 күн бұрын

The lack of creativity of developers will NEVER cease to amaze me

LLL: "It's from 20 years ago, 2006." Me: "It's not THAT long -- Oh shit..."

@mephistovonfaust

Ай бұрын

Yeah, my mind jumped to the 90s as well

@eypandabear7483

Ай бұрын

@@mephistovonfaust20 years ago is, and forever shall be, the 80s.

@prototypeinheritance515

Ай бұрын

you're old

@axelfoley133

Ай бұрын

@@prototypeinheritance515 respect your elders, boyo. ;)

@friedmule5403

Ай бұрын

LOL exactly! :-) For me is 10-15 years ago in the 1980s and last year is about 2001. :-)

"Everyone can do it" - Yeah for now nobody was able to do it on a 64 bit system only on 32 bit systems lol.

@ssamout

Ай бұрын

just was about to comment that "everyone"-line. I doubt my mom could time the attack right.. she always forgets to compensate for latency...

@wombatdk

Ай бұрын

Nor if there's a connection limit via firewall. Even with the biggest botnet it would take forever.

Can I just say this? Thank you Low Level Learning for dark mode. So many yt chanels flash bang me.

@Kane0123

Ай бұрын

Nothing worse than when a KZreadr bangs you, that’s for sure

@SB-qm5wg

Ай бұрын

Agreed 👏

@_Salaar_khan

Ай бұрын

I wish a KZreadr bangs me too someday

@benja1378

29 күн бұрын

@@_Salaar_khan 😂😂😂

I think at this point we can update the saying to "the three hardest problems in computer science are cache invalidation, naming things, asynchronous programs and 'Off By 1' errors"

@BillAnt

29 күн бұрын

Throw in interrupts like SigAlarm and you got a nightmare.

@mattman1864

29 күн бұрын

@99temporal I see what you did there

@prophetzarquon1922

29 күн бұрын

2B OR ≠2B

@off-by-one

3 күн бұрын

I endorse this comment.

Bugs like this are part of why I use a pretty aggressive fail2ban. The attacker doesn't get 10,000 tries... instead they get 3 tries or sometimes even less. The bans eventually expire, but instead of hours to get in, it would take decades. Plenty of time to install a fixed version.

@danmerillat

Ай бұрын

You can get nailed on the first try if you're unlucky, or the timing might never work for an attacker. Even 64 bit systems could get catastrophically unlucky. At least it's an easy fix this time.

@parad0xheart

Ай бұрын

fail2ban is certainly a useful tool, but I can think of way to potentially dodge it, depending on how it's coded. Like most software, let's assume that it's been written with the assumptions of the IPv4 address space in mind. That is to say, a user is likely to have access to a handful of IP addresses, and can't easily get hold of more unless they are a large company or state actor. However, that's not true for IPv6, where essentially everyone gets access to a 64-bit block as normal practise. So if fail2ban isn't coded to take this into account, and is only banning singular IP addresses, then it's trivial to bypass with IPv6...you just change IP address on every operation. To counter this, fail2ban needs to be IPv6 aware, and ban the whole 64-bit block if just one address in it trips its alarms.

@ToyKeeper

Ай бұрын

@@parad0xheart There are ways to make it detect and block IP ranges, in both ipv4 and ipv6. It just depends on whether the admin actually bothered.

@Daniel15au

Ай бұрын

​@@parad0xheartI'm not sure about fail2ban specifically, but it's standard to block the whole /64 range for IPv6. Each customer / network is supposed to get its own /64, so it makes sense to block the entire range.

@mbabuskov

Ай бұрын

@@parad0xheart or you just disable IPv6 for SSH, by setting the protocol to "inet" in ssh config.

oh that is why an openssh update was avaliable.

@johndank2209

Ай бұрын

They patched it already?

@privacyvalued4134

Ай бұрын

@@johndank2209 It was probably patched before the paper and the CVE were announced. Package maintainers get early access to security fixes so they have ample time to prepare their backports. A backport is a fixed version with security patches applied retroactively. It's how most distros work. Since many packages are binaries, they can even advance patch most systems before the actual source code changes becomes available from the OG repository. It depends on the severity of the vulnerability, but package-managed systems can actually be fully patched up to a week before the CVE drops.

@dzaqwanamir

Ай бұрын

@@johndank2209 it was revealed as the patch is out

@Kyle-Jade

Ай бұрын

Yeah Ubuntu already patched it up on July 1st openssh 1:9.6p1-3ubuntu13.3 CVE-2024-6387 Edit: From the bug report itself 2024-05-19: We contacted OpenSSH's developers. Successive iterations of patches and patch reviews followed. 2024-06-20: We contacted the distros@openwall. 2024-07-01: Coordinated Release Date.

@stevegredell1123

Ай бұрын

@@johndank2209 it was an accidental regression, should be super easy to patch. Just revert the code that was never supposed to be there anyway

I use sssh. Safer ssh

@ACium.

Ай бұрын

there is no such thing as "safe"

@HAAAAAAAAHHHHHH

Ай бұрын

ssssssshhhhhh

@asdprogram

Ай бұрын

@@ACium. sshhhh, its "safer", not "safe"

@cringemaki

Ай бұрын

Hahaha I see what you did here!

@JoachimFosse

Ай бұрын

Don't google sssh 🤣Straight to PH

This has all my windows people at work scream LINUX VIRUS and im so exhausted of telling them it would take literal hours and using fail2ban is a dead simple mitigation any public server should have anyway. Ugh... That said, this explanation was really good! Reminds me of the late Tetris level shenanigans where VBlank interrupts cause almost the same situation - albeit of a different nature.

@mnarath8376

Ай бұрын

the regression has been fixed anyway already even my old ubuntu lts jammy pi home server already got a patch for it

@marcelocardoso1979

Ай бұрын

Like OpenSSH is not present on Windows also...

@somebodystealsmyname

Ай бұрын

Be sure to update your fail2ban sshd filter after installing openssh 9.8 ;)

@KevinVeroneau

Ай бұрын

This is also more exploitable as the paper mentioned on 32-bit CPUs... which in 2024, who is seriously even using 32-bit for anything, let alone a server on the Internet for anything productive? So, this is essentially a very minor issue in my eyes and shouldn't affect that many people or servers.

@nikolaikalashnikov4253

Ай бұрын

...i have heard whispers & jokes of "Linux" & "packet sniffing": But they're so busy laughing that I cannot understand what they're saying... Can you comment on this at all ?

very well explained. i love that the vulnerability is put under real word context and report is not just a scary click bait. if one has a cloud server e.g. amazon, they should limit their client IP address for that ssh port.

@leokappler2282

28 күн бұрын

Is that the recommended method? I also always thought It would be risky to use an ssh server outside my home network. But don't know what to do instead. What if there is a coffee shop with the same provider and open wifi nearby. Wouldn't they also have the same IP? Of course it would still be a lot harder to hack the server than.

@test40323

28 күн бұрын

@@leokappler2282 , your ISP typically assigns an unique but non-permanent address for each location. so your server would see different ip address at your coffee shop vs your home address unless you tunnel through your home address.

Please add sections to your video! 🙂 Especially for experts, it is nice to skip stuff like explanations what SSH is.

@MoonlightCheese-0

Ай бұрын

@@ForcefighterX2 +10000000

That's it, you're going into the Rust rewriter

Just wanna say I love your vids man , high prod quality and clear description of the issue.

Great job explaining this vulnerability. But I think you got the LoginGraceTime part wrong. According to sshd_config's man page: "The server disconnects after this time if the user has not successfully logged in. If the value is 0, there is no time limit." - Which could result in a DoS if the maximum unauthorized connections are exhausted.

@bertjanbakker9497

28 күн бұрын

That's exactly what the paper points out. (10:58)

10:51 It does not close it immediately but rather does not close it at all. That's why as researchers mention it make you vulnerable to dos attacks as attacker does not have time limit for spawning too many waiting logins

@jakx2ob

Ай бұрын

Which could easily be a bigger problem than a vulnerability with no known exploit.

Finally! I don't have to worry about forgetting my password anymore.

Oh boy, the rewrite in rust gang is coming!

@RingingResonance

Ай бұрын

OH LAWD! HE COMIN!

@gavabundo_0072

Ай бұрын

Is Rust also Thread Safe?!

@aria2398

Ай бұрын

@@gavabundo_0072that’s like half the whole point

@deanjohnson8233

Ай бұрын

@@gavabundo_0072 This vulnerability is about signal safety - that is a whole other level of safety that Rust does not provide. When the signal handler is invoked in this exploit, the heap is corrupt. If you do anything with the heap at that point, you are bound to have something exploitable and a signal handler is Rust CAN interact with the heap.

@PhantomPhobos

Ай бұрын

we gonna be ruSHing

@0:27 "...not that scary" Title: ABSOLUTELY WILD !!!! 😂😂

@RobTheQuant

Ай бұрын

great point! 🤣

@szelest88

Ай бұрын

Think of a giraffe. Wild? Wild. Scary? Not so much.

@jiribrabec2100

Ай бұрын

This is how we all live now

@arthurmoore9488

Ай бұрын

@@szelest88 Yeah, what they pulled off is insane and I now have much more respect for that company. I may actually attend their next webcast.

@jawwad4020

Ай бұрын

@@szelest88 *a wild exploit has appeared* 😆

Interesting video & well explained. I'll be coming back to this channel for more content like this, good stuff! 👍

Your explaination for laypersons is very very good. I'm not a programmer or security expert by any means, but found it was easy to comprehend thanks to your summary

What an excellent explanation, you are a great teacher. Subscribed!

This is a really high quality and useful video for me. It makes me look smart to my bosses. Thank you :)

I don't personally like your implied criticism of open source software twards the end of these kinds of videos. While I understand being cautious, it makes it kinda feel like its somehow a bad solution to an other wise worse alternative. Personally I think instilling fear in something that has been the better choice in security since the dawn of the internet is not a good idea. I do agree that its not perfect, but until theres an objectively better option, I would prefer that you didn't make it sound as if the world is going to collapse because we rely on the better of our options in software security.

I think one of the best things you can do to secure your own Internet-connected server is to set up a system where you touch a specific port in a specific way to open up another port forward for the actual service. Without the initial poke at the ports, the server is never exposed to the Internet directly.

@zoomosis

29 күн бұрын

I believe this is known as "port knocking".

@forbiddenera

28 күн бұрын

This is just security through obscurity.

the last time I was this early the queen was still alive

@MenaceInc

Ай бұрын

The Queen is still alive though? 🤔 I'll be embarrassed if I check the news and see that Camilla has died...

@mochafennec

Ай бұрын

@@MenaceInc The Queen that actually mattered, not the current one

@MenaceInc

Ай бұрын

@@mochafennec Victoria? Zenobia? Cleopatra? Freddie Mercury?

Great coverage on the subject when everyone else is screaming everything could be on fire. Seriously though big points to reviewing the mitigations and explaining the exploit in a easy to consume video!

A phrase to parallel JerryRigEverything: “Code is code, and code breaks”

@spok_real

Ай бұрын

@@callumbirks I have written unbreakable code observe int main() { return 0; }

I swear every time I get a notification from low level learning it's some scary vulnerability that may affect one of my systems

kind of video you wanna see right after starting openSSH

@Karstadtdetektiv

Ай бұрын

frfr just setup my vps yesterday for a minecraft ds-lite nat proxy tunnel and well haha sudo apt update sudo reboot

@Brahvim

Ай бұрын

Same! I learnt more about `ssh` and `tmux` JUST YESTERDAY and now I get to watch this! ... Thank you, Ed. At least I know how to keep my `ssh` connections more secure _nauw!..._

Crazy exploit! Thanks for making me aware to this

Great video and breakdown!

This sounds like an early implementation of a TAS speed run with a wrong warp. It sounds impossible to execute but determined people can make these issues exploitable at a moment’s notice.

@lborate3543

Ай бұрын

Yuffie mentioned.

Great video and explanation

I sent a similar video to someone at my office. He's like: updating the libraries now. We then talked about the importance of testing known weak points in code (since it was a regression). Gotta keep an eye on known previous points of failure.

Great stuff. Thanks ever so much LLL!

I wanted to touch on something you noted late in the video, regarding recommending not exposing SSH on the internet, which invites the question of what do you suggest instead? You can do a lot to try and isolate management networks/etc, but ultimately you need a legitimate way in. Your argument that 'code can have bugs' applies to pretty much anything, we've seen various firewall vendor and VPN bugs in the past, so they're not different. How would you handle remote access?

@LowLevelLearning

Ай бұрын

unfortunately imo the only other way is IP address whitelisting. it's not pretty but it significantly reduces the attack surface

@NigelVH

Ай бұрын

@@LowLevelLearning I can agree with you on that. Sometimes that presents a practicality problem, but it does significantly improve the posture when possible. And then in the case of this particular bug, something like fail2ban would probably go a long way in mitigation (though not closing off the bug entirely), given the large number of tries required. Thanks as always for the great content!

@ToyKeeper

Ай бұрын

@@NigelVH One low-tech way to reduce risk is to require a port knock or similar. It's primitive, but still sufficient to stop most attacks.

@smc4229

Ай бұрын

Run SSH on a non-standard port, use fail2ban, or limit what IP blocks you allow to access (if you're in the US, do you need to allow access from other continents?). For big organizations that have their own IPv4 blocks they got from a RIR it's super easy, you just only allow from your own IP blocks and reject everything else

@futuza

Ай бұрын

I think he was referring to don't connect it to the internet while using the vulnerable version, not don't use SSH for its intended purpose ever. If that's what he did mean, then there's a couple of things you can do like whitelisting only specific IPs, or port knocking, but these only reduce the attack surface not make it safe. IMO its worth the risk if you take proper cautions like, IP address whitelisting, but not using a tool just because there's a possibility it could be vulnerable is dumb.

This is literally the meaning of "grace" and since it was implement it has always been known to be a potential vulnerability.

yo, i'm no code guy but enjoy stuff like this from u, primeagen, dave's garage n the likes, i appreciate the logic n informative value u guys bring

Great content! Thank you!

That seems like an art piece or concept work... A meandering of what's possible, might not be practical but possible and clever none the less.

Reminds me of one of the exploits in the chain for Eternal Blue.

It's amazing, the blogger is really creative and worth watching

Can you imagine any legacy devices common on local networks that use the vulnerable ssh? Perhaps even those not owned by the user

How well can that 4-6 hours be parallelized? If an attacker can work on thousands+ of targets simultaneously then it still seems pretty bad

@somebodystealsmyname

Ай бұрын

You need a pretty stable connection for race conditions. So, working on thousands of targets would be extremely expensive.

@namm0x326

Ай бұрын

@@somebodystealsmyname Establishing SSH connections costs very little bandwidth. Depending on the exact timing, AWS may not be enough. But a small host with good connectivity to your target ranges, which can be established with a BGP looking glass, and many of these have very limited to no KYC -- those are great for these attacks

@danmerillat

Ай бұрын

already covered in the video. OpenSSH throttles new connections to... 100 in a second? which is why it takes 3-4 hours based on how quickly it allows connections to come in.

I mean yeah you're right, this isn't the kind of exploit to some random individual is going to use to hack into a bunch of servers. But for extremely sophisticated, targeted attacks, stuff like this can be and is exploited.

Finally! I found someone that also pronounces it as 'daymon' instead of 'deamon'! A.k.a. the correct way!!!!!

Was waiting for this vid

thanks for the great explanation.

"Would rust have fixed this bug?"

@llamatronian101

Ай бұрын

Yes. You can screw up with signals in Rust, but you kind of have to try.

@deanjohnson8233

Ай бұрын

I don’t think so. A signal handler in Rust can interact with the heap which will expose you to similar issues. At the time the signal handler is invoked, the heap is in a corrupt state. There is surely a way to exploit that, even if it isn’t exactly the same bug.

@llamatronian101

Ай бұрын

@@deanjohnson8233 signals would typically be handed by Tokio or some other crate like signal_hook. These would avoid mistakes like interacting with the heap inside a signal handler. Rolling your signal handling in Rust would count as trying to be insecure to me.

@SanguinariusUmbra

Ай бұрын

​​@@deanjohnson8233Hol' up. The paper mentions "if any one of these 24 free() calls is interrupted..." and "hence free(), which is not async-signal-safe". Generally in rust, whether you're in async or sync code, the compiler makes sure all the memory is deallocated once an item goes out of scope. This stands true even if the thread panics. On top of that, you also have the type system that prevents you from using and sending non async-safe types (including functions) across multiple threads. I'm pretty sure there are still ways to screw up, but rust would make it very hard to do in the first place.

@ChrisWijtmans

Ай бұрын

@@SanguinariusUmbra yeah but the lower levels arent made in rust. So rust is dead in the water.

5:05 maybe I’m just out of it but has anyone else had the thought “Malloc Baldwin” randomly before? Internet, please say I’m not alone in this 😅

I rarely had to do signal handlers but the first thing I do is making sure no mallocs are reachable.

What a champ and good explainer.

For critical projects like this (at the very least), there should be a process built into the commit procedure that checks for various types of vulnerabilities, and especially for specific vulnerabilities that were previously found and patched.

Bro said "code is code." genius.

Good thing I had to power off my server due to no electricity

I think you’re the only youtuber who covers this with proper manner instead of reading some news outlet who wrote no background of programming

Love your content.

"Accidentally"

"keep SSH off the internet" significantly dings the usefulness of SSH though. people will continue to use SSH as their primary method for accessing VPS instances for the forseeable I think

@Patmorgan235Us

Ай бұрын

You just need to use a IP whitelist or a VPN

So if i understand correctly, the exploiter injects the required function pointers for shell root onto to the compromised heap via the certificates being sent?

Next major version, rewritten OpenSSH with Rust.

Basically while the OpenSSH "regreSSHion" vulnerability sounds concerning, it's not a major threat. Exploitation is complex and requires hours of attempts under specific conditions, making widespread attacks unlikely. Many systems already have mitigations like brute-force detection in place, and the scope is limited to certain OpenSSH versions. Patch your systems ...no need to panic.

people incorrectly assume that updating your software to the latest version is safer than running older code

@mnarath8376

Ай бұрын

well since they patched out the regression right now it is

that sounds a lot like the kind of attacks that first kinds of hacks found on consoles to bypass protection

Everything else aside, I'm really happy the paper starts by quoting The Interrupters.

"Don't expose your ssh to the internet" Prime's startup in shambles

and this is exactly why i never expose ssh to the internet, but rather behind a preconfigured wireguard intranet.

Thx for ur efforts to do this video, one simple question, wouldn’t be awesome if the developers of OpenSSH project rewrite most of their base code using Rust language! Due to enormous hype about it, in which of its core features eliminating race conditions and other memory faulty stuff?!

Thanks.

Great vid!

who the hell are runnings 32bit server applications in the current year

@islamicstateofukraine

Ай бұрын

more common than you think

@olnnn

Ай бұрын

probably a lot of low power embedded computers like routers and what not, many that no longer get updated

@Karstadtdetektiv

Ай бұрын

Raspberrys maybe but they should not be connected directly to the internet anyway.

I still remember the first time I had a server open to the internet the only reason I didn't get hacked is because the logs from their attack filled my 40gb drive and crashed the system. Something like this would have been very bad.

The authors of the paper quoted song lyrics by a band called The Interrupters in each chapter.

good to see that ASLR is almost doing the job it's designed to do. #speedbump

Would you be able to do a video explaining ASLR? I understand the basic concept, but don't understand how it doesn't cause code to break.

Damn he really exposed it. This was a closely guarded secret for years 😣

2:55 yeah that article is thicc!

"In this video we'll discuss why at the end of the day it's not as scary as people are making it out to be." Video title: "new SSH exploit is absolutely wild" 😂

@charetjc

Ай бұрын

It is an exploit. How it works is absolutely wild. Doesn't mean it's quick, easy, or ubiquitous that everyone needs to run screaming from some impending horror.

Does this mean that a bunch of SSH enabled devices that manufacturers have locked down can now be cracked open for legitimate reasons?

@Karstadtdetektiv

Ай бұрын

Not sure about x86 / ARM thing but if 32bit just means 32bit then - yes.

If a hacker manages to hack my server with this exploit they deserve everything on it at that point

@Karstadtdetektiv

Ай бұрын

somebody will just make a nice metasploit script so everyone can use this with a single line and ip to get a reverse shell. right now - hack me daddy - stuff haha :D

Some researchers find wild exploits like this. Others figure out how to program Flappy Bird in Super Mario World using nothing but a controller and stock hardware.

@LowLevelLearning Have they completed the 64bit PoC yet? Last I saw they still only had only successfully exploit in 32-bit. However, they were working on a 64-bit version

I would argue that the root of this problem is the complexity that signals introduce due to their ability to interrupt critical code. It’s hard for a developer to anticipate every possible place a signal might interrupt execution. A smart developer really should avoid the use of signals for application functionality.

"Don't expose ssh the the internet !" Good idea. What shall I expose to drive a server ?

Not me typing in my shell ssh -V asap

oh yeah, be sure to be up to date for all the security fixes

I love how a serious RCE gets resurfaced because "oops I [un]commented the wrong #ifdef" AKA how often does stuff like this make it into open code bases because no one notices? Who knows if this oops was intentional or not.

Noob question, is LibC needed for system runtime, or is it an optional component used for compiling and so on?

"re evaluate your life" did this guy just tell me to unalive lmao

@Brahvim

Ай бұрын

_nu._

Every time when i see exploit like this i wonder, maybe it is not feasible for remote access, but could be used for privileges escalation for local users and rooting phones, consoles etc.

I am a little bit perplexed. Firstly, removing openssh from the Internet may be an option for some, but many hosting providers actually allow clients to use ssh to update their files on the host. For them to remove ssh from the Internet would mean that clients have lost the ability to upload files to their host (or at least have lost that path by which they can upload). Secondly, if this problem is in malloc(), the I would think that potentially it has far wider issues than merely OpenSSH, malloc() is a core part of memory management on most systems (even if it is behind the scenes), and it would seem very probable that there are other pieces of software out there that allow signal interrupts while using malloc().

@lillones

Ай бұрын

Use sshv2 straight up instead of using unsecure free replacement programs. On top of that, dont allow direct internet access to the ssh port of those servers. You could easily implement a vpn that could provide access to whatever management is needed securely

@Hfil66

Ай бұрын

@@lillones none of these alternatives are guaranteed to be any safer than OpenSSH. If the problem is the way malloc() interacts with signals then there is no reason to be so certain that a VPN would not have the same issue. All that a closed source alternative to OpenSSH would give you is the bliss of ignorance - you same problems might be there but it would take a lot longer to find them.

@lillones

Ай бұрын

The vpn would allow you to send requests for ssh internally on the intranet rather than the open internet. It would block any rando from being able to even attempt to initiate a session to take advantage of the vulnerability

@Hfil66

Ай бұрын

@@lillones yes, but the VPN itself is using an encrypted tunnel just as SSH does.

@lillones

Ай бұрын

@@Hfil66 yes... and water is also wet, but that has nothing to do with my point

The way you say qualys as "qualles" 0:12 😵‍💫

Автор видоса рассказал про отличную связку, давно на вас подписан в тг!

"When you use OpenSSH 4.4 reevaluate your life" Me nevously now checking all VMs, SBCs etc. 😅

This is yet another reminder that the original release mentioned this is excruciatingly hard to exploit, and trivial to mitigate. Remember to breathe.

timing here is interesting. would an attack perhaps be exploitable faster with less network latency deviation (e.g. intra-datacenter exploits) i would presume attack could be performed much faster if you knew additional information about where in the cloud your victim is hosted and network link speeds are much more predictable.

@somebodystealsmyname

Ай бұрын

The 10000 tries the researchers got were under lab conditions. So it will mostlikely be longer in real world conditions.

@LevaniaMeyano

Ай бұрын

Think the research group the lowest latency they were attempting at was 10ms or something crazy low like that.

So simplest way to protect is set LoginGraceTime = 0 and all even old versions sould be "safe". Is this exploit only for x86 arch? does arm32 also affected? Thinking about rasberry pi platform connected to web.