full-disclosure - irc over ssl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <01b401c44188$f9df3890$c71121c2@exchange.sharpuk.co.uk>
From: DaveHowe at cmn.sharp-uk.co.uk (Dave Howe)
Subject: irc over ssl

Giannakis Eleftherios wrote:
> are there any known issues concerning rootkits, backdoors, cmd
> execution concerning an irc(with ssl) client ?
The answer to the question as posed is No
However, the *real* answer to the question is to componentize the four
items we are discussing, and query each individually.
1. The IRC Client
The client may well have overflow or other vulnerabilities, either
currently or in the version you are using.

2. the ssl client
The client (either module, standalone utility, or builtin for your IRC
client) may have vulnerabilties. It may also be vulnerable to bypassing
(for example; most IRC+SSL combos do not encrypt XDCC chat traffic, but
don't indicate this failure anywhere

3. The SSL server
as client

4. The IRC server
many IRCd have historically had vulnerabilities; some can be abused to
exploit what should be a trusted transaction (eg, XDCC send setup) and
substitute an unsafe or infected file for the file you and your
correspondent were expecting to exchange.

> I use the irssi client
There are currently no published 'sploits or theoretical vulnerabilities
for this client.

> to conect to a irc server with ssl.Is there a way for the admins of
> the irc server to open/intrude somehow to my pc(through the high port
> that the client opens to conect to the server)?
They could at best exploit a vulnerability in irssi (if there is one) that
requires an open connection (eg, a buffer overflow in a server-generated
message packet; this is slightly more likely than such in a
user-interchange packet, as much software "assumes" servers are
well-behaved). They can of course also monitor any non-XDCC traffic just
like they could if your connection was not SSLed, provided they patch the
ircd to that end.