If you can't tell by the number of posts next to my name, I'm new to the defcon forums. I was just wondering if this was an appropriate forum for discussing unpatched exploits?
Announcement
Collapse
No announcement yet.
Current Exploits
Collapse
X
-
Originally posted by Mr. PeabodyIf you can't tell by the number of posts next to my name, I'm new to the defcon forums. I was just wondering if this was an appropriate forum for discussing unpatched exploits?
If you mean how you are dealing with them from a security standpoint then yes. If you mean, and judging from you other few posts I doubt this, "1 @m 50 1337 l00k a7 my ub3r 1337 z3r0 daz3" then no.perl -e 'print pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
Comment
-
Originally posted by ChrisIf you mean how you are dealing with them from a security standpoint then yes. If you mean, and judging from you other few posts I doubt this, "1 @m 50 1337 l00k a7 my ub3r 1337 z3r0 daz3" then no.Last edited by Mr. Peabody; February 3, 2004, 23:08.
Comment
-
Originally posted by Mr. Peabody...like the recently growing trend in kernel module exploitation available in linux and bsd flavors as well.45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B0
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B1
[ redacted ]
Comment
-
Originally posted by basculeWhat trend? Neither Linux nor *BSD has had a module loading vulnerability in recent history...
> > Such kind of kernel backdoors (e.g. loadable kernel modules) are also present for Solaris, *BSD and Windows systems. If you are unsure whether someone has compromised your system, don't trust the system's kernel!
/***********************************************
*
* Linux Kernel Module Loader Local R00t Exploit
* Up to 2.4.20
* By anonymous KuRaK
*
************************************************
You sure this doesn't exist?
Comment
-
Oh, the ptrace vulnerabilities. I wasn't aware there was module loading involved as a part of the exploitation vector.
Well, what particularly did you want to discuss about them?45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B0
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B1
[ redacted ]
Comment
-
Originally posted by basculeOh, the ptrace vulnerabilities. I wasn't aware there was module loading involved as a part of the exploitation vector.
Well, what particularly did you want to discuss about them?
Comment
-
Originally posted by Mr. PeabodyNothing really, I was using familiar concepts to get an understanding of the ground rules and such. They were merely used as an example.
"...A number of significant potential security deficits remain undisclosed in advisories concerning YM is the distinct absence of encryption. Users may send sensitive data via messages or file transfers, both of which are routed across the Internet. This lack of encryption coupled with a lack of a secure layer within the YM protocol stack could be used by a third party to access supposedly secure communications. As already highlighted file transfers in YM reveal a users IP Address. If an attacker is able to persuade an unsuspecting user to send or receive a file, with a quick look in netstat the IP Address is revealed. Should the unsuspecting user be making use of a fixed IP, this could be very bad news indeed (either through direct hacking attempts, harassment or DoS attacks). Because YM sessions are based on clear text it is possible for a malicious user to perform a TCP hijack on an active/idle connection. Using this method it is possible for a suitably skilled computer user to impersonate a legitimate YM user to obtain sensitive data."
I read the article at www.hackwire.com
The author listed his source as www.iss.netLast edited by Floydr47; February 8, 2004, 19:08.I enjoy talking to myself...it's usually the only intelligent conversations I get to have.
Comment
-
Originally posted by Floydr47I ran across an interesting article while surfing, on YIM vulnerabilities.
"...A number of significant potential security deficits remain undisclosed in advisories concerning YM is the distinct absence of encryption. Users may send sensitive data via messages or file transfers, both of which are routed across the Internet. This lack of encryption coupled with a lack of a secure layer within the YM protocol stack could be used by a third party to access supposedly secure communications. As already highlighted file transfers in YM reveal a users IP Address. If an attacker is able to persuade an unsuspecting user to send or receive a file, with a quick look in netstat the IP Address is revealed. Should the unsuspecting user be making use of a fixed IP, this could be very bad news indeed (either through direct hacking attempts, harassment or DoS attacks). Because YM sessions are based on clear text it is possible for a malicious user to perform a TCP hijack on an active/idle connection. Using this method it is possible for a suitably skilled computer user to impersonate a legitimate YM user to obtain sensitive data."
I read the article at www.hackwire.com
The author listed his source as www.iss.net
I really don't see how that is an exploit any more than sniffing telnet or ftp sessions are exploits. It's a clear text service...so is http, so is smtp. If you are sending anything sensitive without understanding that you need encryption you pretty much deserve what you get.perl -e 'print pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
Comment
Comment