bugtraq - Re: [SECURITY] Remote roster manipulation bug in various Jabber clients

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] [day] [month] [year] [list]

Message-ID: <D7FB2D8A-ACD2-11D7-AB59-000393B4C928@jabber.org>
Date: Wed, 2 Jul 2003 17:19:19 -0400
From: Julian Missig <julian@...ber.org>
To: jdev@...ber.org
Cc: bugtraq@...urityfocus.com, jadmin@...ber.org
Subject: Re: [SECURITY] Remote roster manipulation bug in various Jabber clients


On Wednesday, Jul 2, 2003, at 16:53 US/Eastern, Jamin W. Collins wrote:

> On Wed, Jul 02, 2003 at 10:05:11PM +0200, Jacek Konieczny wrote:
>
>> 3. Impact
>>
>> The attack cannot be done from Jabber client connection to jabberd
>> 1.4.x server because of similar bug (or feature) in this server - it
>> doesn't check "to" attribute and all such <iq/>s treats as directed to
>> the server. Attacker roster stored on server is modified instead of
>> victims ones.
>
> Wouldn't this still be a concern?  The roster on the server would be
> modified and only corrected if the client exited properly, thus
> resyncing it's list to the server, right?

Why would it be a concern? It's the *attacker's* roster which would be 
modified in that case, not the victim's. As an aside, clients typically 
do not "resync" their lists to the server when they exit.

Julian