From: Erik L. <er...@ho...> - 2012-05-31 04:58:22
|
Sending this on behalf of my senior engineer, hopefully someone can shed some light on this. /Erik -- I think I've found a bug, but I'm trying to verify it because what I have as a client can't communicate to the server. Upon debugging the server I discovered a few issues: inside turnserver_process_turn: if(!(STUN_IS_REQUEST(hdr_msg_type) && method == TURN_METHOD_ALLOCATE)) If you send a 'send method' 'indication class' without a username / password the server is checking for a username and password anyway because the logic check isn't quite right. The RFC specifically states the send indication doesn't include credentials: Send and Data indications cannot be authenticated, since the long- term credential mechanism of STUN does not support authenticating indications. This is not as big an issue as it might first appear, since the client-to-server leg is only half of the total path to the peer. Applications that want proper security should encrypt the data sent between the client and a peer. Because Send indications are not authenticated, it is possible for an attacker to send bogus Send indications to the server, which will then relay these to a peer. To partly mitigate this attack, TURN requires that the client install a permission towards a peer before sending data to it using a Send indication. I discovered it doesn't work right when testing with my own client. Another issue I have is: char bigbuffer[256]; debug(DBG_ATTR, "Source is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&saddr)->sin_addr), &(bigbuffer[0]), saddr_size)); debug(DBG_ATTR, "Destination is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&daddr)->sin_addr), &(bigbuffer[0]), saddr_size)); debug(DBG_ATTR, "Destination is %u\n", ((unsigned long)(&daddr))); turnserver_relayed_recv(buf, nb, (struct sockaddr*)&saddr, &daddr, saddr_size, allocation_list, speer); put in the first part of the code inside turnserver_relayed_recv: debug(DBG_ATTR, "Source (2) is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&saddr)->sin_addr), &(bigbuffer[0]), saddr_size)); debug(DBG_ATTR, "Destination (2) is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&daddr)->sin_addr), &(bigbuffer[0]), saddr_size)); debug(DBG_ATTR, "Destination (2) is %u\n", ((unsigned long)(&daddr))); after the call the "dest" those address values change... but maybe i'm just tired out and doing something wrong... typo can cause anything to happen.. The value "saddr/daddr" is proper before calling the method but then corrupted. Strangest thing... -Robin |