1) Open source isn't more secure. This is an old assumption. 2) There is no such thing as closed source anymore. Everything is chocked full of open source.https://twitter.com/hackerfantastic/status/1072533649411751937 …
-
-
Replying to @joshbressers
I disagree, the reason nobody paid much attention to telnet in inetutils is because a) nobody uses it and b) it's not security sensitive. telnet isn't setuid, and if you can set DISPLAY, you might as well just set LD_PRELOAD, or use !sh to just run commands.
2 replies 2 retweets 32 likes -
Replying to @taviso @joshbressers
People do use OpenSSH and it *is* security sensitive, and you better believe people study every line. I wouldn't trust any proprietary SSH implementation.
2 replies 6 retweets 36 likes -
Replying to @taviso @joshbressers
Hacker Fantastic Retweeted Hacker Fantastic
He is not wrong, though USER= is passed via -l and could be set in a URI handler via user@ making it more interesting as the heap code be remotely reachable -https://twitter.com/hackerfantastic/status/1065095950606221312?s=19 …
Hacker Fantastic added,
Hacker Fantastic @hackerfantasticI've never seen "encryption-free" SSH, I didn't believe it was real - so I looked it up.@mikrotik_com permit you to login via password based authentication over SSH... in clear-text! My password is "SECRETKEY" and can be clearly seen once "none" is selected as a cipher type.
pic.twitter.com/sBM2MRs7sR2 replies 0 retweets 8 likes -
Replying to @hackerfantastic @joshbressers
Do you have an example of any vulnerable usage? It's hard to believe anybody is doing that, that's what I mean: I don't think anybody spent any time auditing telnet from inetutils, because it's not used anywhere security sensitive.
5 replies 0 retweets 6 likes -
Replying to @taviso @joshbressers
telnet has been removed as a URI handler from modern browsers, there are plenty of embedded devices with restricted shells though.
1 reply 0 retweets 0 likes -
This Tweet is unavailable.
-
TLDR; my advisory, shell subsystem removed as is common in restricted environments.
1 reply 0 retweets 0 likes -
here is a proof-of-concept exploiting these vulnerabilities in a malicous telnetd implementation, by providing oversized terminal environment variables to corrupt the heap (as per my original description of the flaw) https://hacker.house/releasez/expl0itz/telnet_term_0day.py …
1 reply 1 retweet 1 like
Nice, but that is a different vulnerability, right?
-
-
Replying to @taviso @joshbressers
No, I just provided more examples of how these issues can be triggered or reach. As the original advisory stated "multiple overflows", one stack overflow through sprintf, others through environment handling in client and also through client/server interaction (PoC).
1 reply 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.