[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Delivery Status Notification (Delay)

This is an automatically generated Delivery Status Notification.

THIS IS A WARNING MESSAGE ONLY.

YOU DO NOT NEED TO RESEND YOUR MESSAGE.

Delivery to the following recipients has been delayed.

       SKelley@xxxxxxxxxxx




Reporting-MTA: dns;mail.tecedge.net
Received-From-MTA: dns;spammotel.com
Arrival-Date: Thu, 17 Jul 2008 08:56:34 -0400

Final-Recipient: rfc822;SKelley@tecedge.net
Action: delayed
Status: 4.4.7
Will-Retry-Until: Sat, 19 Jul 2008 08:56:34 -0400
X-Display-Name: Stephen Kelley
--- Begin Message --- 


slush wrote:

Hi to all again,
because it looks like conference did not receive emails with attachments, Im resending my initial email about problem I found. Attachments from original email are here: 
http://www.slush.cz/centrumyahoo.png
http://www.slush.cz/centrum.png
http://www.slush.cz/centrumok.png

Regards,
Marek
On Thu, Jul 17, 2008 at 2:16 AM, slush <slush@xxxxxxxxxx <mailto:slush@xxxxxxxxxx>> wrote: 

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Hi all,

    I dont have better contact (I cannot find any bugzilla for Tor), but I
    have to say, that there is serious problem in Tor (using last
    0.2.0.30 <http://0.2.0.30>
    version). It looks like buffer overflow, but I dont know, if it is
    problem of client or exit node (I dont suspect relays).

    In attachment, you can see three screenshot of the same page. On two
    of that, there are big artefacts from other pages (first of them is
    yahoo - see "Yahoo privacy policy", second is unknown - Serbia? -
    website). Because Im not using yahoo and I dont speak Serbia, these
    pages are not from my cache (latest stable Opera without any plugin).

    On third screenshot is original look&feel of centrum.cz
    <http://centrum.cz>, one of
    biggest portal in Czech Republic. It is almost impossible, that this
    is problem on their side. I hear about this Tor problem before weeks,
    but I did not believe that.

    Some IMPORTANT additional info. I found this bug when I broke my
    program using Tor, that he created very much circuits thru Tor (~ 1000
    circuits at the same time). I think it is very important for this
    description. On other case, I created them using standard Tor
    interface (extend circuit command on tor controller) and Tor did not
    say me about any problem. So it is definitely bug of tor (even if
    suspect, that 1000 circuits are not standard behaviour).

    Unfortunately, I dont know, which exit node serves me when error
    occured, so I dont know version of exit node :(

    Regards,
    slush (admin of tor relays slush and mwserver)


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: http://getfiregpg.org

    iD8DBQFIfo9Hr7KgZiv8EokRAskDAKCuYxXcd4g3beMQP4Lj/4awpXBoeQCeM7OV
    rnAkbBw/a8ssDO6U92u2qVk=
    =wVDS
    -----END PGP SIGNATURE-----





At first sight this appears to be an exit node problem but then, as I
read it, you say it occurs with more than one exit node and only at this
"higher" level of throughput.

Alarm bells are ringing ... to mix streams up like this then streams at
the "higher" throughput would have to be unencrypted clear streams - yes?

This would mean that either all tor exits are vulnerable and are mixing
the streams. Or that traffic is being passed wholesale *-unencrypted-*
between nodes (so that nodes other than the exit nodes are doing the
mixing).

Sh*ttt.. whatever.. this is a major BUG.

--- End Message ---