[Freeciv-Dev] [bug #20003] Security advisory (CVE-2012-5645, CVE-2012-6083)
Update of bug #20003 (project freeciv): Summary: Security advisory = Security advisory (CVE-2012-5645, CVE-2012-6083) ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Follow-up Comment #24, bug #20003 (project freeciv): (Since this is a security bug: for those watching at home: the post-commit discussion here spawned a bunch of patches intended to make the low-level protocol handling more obvious and the endpoints less tolerant of malformation, e.g. patch #3685, patch #3687. I don't think any new security issues have been identified as a result of this work?) ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Follow-up Comment #23, bug #20003 (project freeciv): IIRC return value is solely about whether data was available (and read). These low-level functions do not know what data is valid. Maybe dio_get_uint8() has a bug? I think so. I will try to investigate a bit deeper... Usually lack of valid data will lead to connection being closed in upper level, but the original bug here was that low-level ended to infinite loop and it never returned to upper level. I understood this point. However, no test is performed in the packets body, or nearly not. I will try to build a more complete patch. ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Follow-up Comment #22, bug #20003 (project freeciv): What value returns the dio_get_xxx() ? According to your comment, I understand that these functions returns TRUE if the value is read and valid. However, the code doesn't match this (for example can dio_get_uint8() returns TRUE even if there was no more byte, functions like dio_get_bit_string() look strange). IIRC return value is solely about whether data was available (and read). These low-level functions do not know what data is valid. Maybe dio_get_uint8() has a bug? Usually lack of valid data will lead to connection being closed in upper level, but the original bug here was that low-level ended to infinite loop and it never returned to upper level. ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Follow-up Comment #21, bug #20003 (project freeciv): Well, third one is what I've planned to do for a long time*: give dio_get_xxx() functions return values telling if they succeeded or failed. Patch attached. *) According to very old TODO I had actually foreseen possibility of infinite loop somewhere when I first came across the dio_get_xxx() functions and noticed their lack of return value. Any volunteers to do throughout checking of all dio_get_xxx() callers in case there's other places where return values (added by this patch) should be checked. When working on porting this patch to warclient, numerous questions came to me. I had also noticed something wrong in those functions, including the case of infinite loops and wrong data for a very long time. What value returns the dio_get_xxx() ? According to your comment, I understand that these functions returns TRUE if the value is read and valid. However, the code doesn't match this (for example can dio_get_uint8() returns TRUE even if there was no more byte, functions like dio_get_bit_string() look strange). I guess that all receive_packet_xxx() functions should also test the results of the dio_get_xxx() ones. Also, shouldn't the server of the client cut the connection of a such packet ? It clearly doesn't match the protocol, so it is not a compatible connection. ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Update of bug #20003 (project freeciv): Open/Closed:Open = Closed Operating System:None = Any ___ Follow-up Comment #20: They've now clarified this http://www.openwall.com/lists/oss-security/2012/12/31/2: * CVE-2012-5645 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5645 = r21701 http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=21701 * CVE-2012-6083 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6083 = r21672 http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=21672 Also, since prlw1 has verified the fixes, I don't see any reason to keep this ticket open any longer. ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Follow-up Comment #18, bug #20003 (project freeciv): These security issues have apparently been assigned the ID CVE-2012-5645 -- see here http://seclists.org/oss-sec/2012/q4/484. (At time of writing it's not associated with Freeciv in the master database http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5645; I assume the description will trickle back later.) ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Follow-up Comment #19, bug #20003 (project freeciv): CVE-2012-5645 They had missed the fact that two issues were reported in this single ticket. CVE description contained both, but they provided only one fix. I informed them about this. I assume they will assign new CVE to the other half (rather than update existing one to contain second fix also, as that would lead to confusion with those who already list current CVE as fixed) ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Follow-up Comment #17, bug #20003 (project freeciv): I have checked your patches against the exploits and they do fix it: 2: Lost connection: c1 from localhost (illegal packet size). for part 1, instead of the out of memory error, and 1: Receiving packet_player_info at the server. 1: Received value isn't boolean: 255 1: last message repeated 2 times 1: last message repeated 2 times (total 4 repeats) 1: last message repeated 4 times (total 8 repeats) 1: last message repeated 8 times (total 16 repeats) 1: last message repeated 16 times (total 32 repeats) 1: last message repeated 32 times (total 64 repeats) 1: last message repeated 23 times (total 87 repeats) 1: received bad string in packet (type 51, len 103) from c2 from localhost (connection incomplete) 1: received short packet (type 51, len 103) from c2 from localhost (connection incomplete) 1: Received game packet PACKET_PLAYER_INFO(51) from unaccepted connection c2 from localhost (connection incomplete). for part 2 instead of a hang. All fixed :-) ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Follow-up Comment #3, bug #20003 (project freeciv):
Thank you for your patch which fixes part A].
As to part B], it seems that the infinite loop comes from this part of
common/generate_packets.py:
pre
544 else:
545 return '''
546 for (;;) {
547int i;
548
549dio_get_uint8(din, i);
550if(i == 255) {
551 break;
552}
553if(i %(array_size_u)s) {
554 log_error(packets_gen.c: WARNING: ignoring intra array diff);
555} else {
556 %(c)s
557}
558 }'''%self.get_dict(vars())
/pre
The only way out of the for(;;) is if we manage to read 255.
(What seems odd is that the exploit seems to send many 0xff's, and I would
have expected the opposite)
___
Reply to this item at:
http://gna.org/bugs/?20003
___
Message sent via/by Gna!
http://gna.org/
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Follow-up Comment #9, bug #20003 (project freeciv): (What seems odd is that the exploit seems to send many 0xff's, and I would have expected the opposite) Problem is that in error situation - when there's no more data - dio_get_uint8() returns 0, not 255. So if there's not enough data, it will try to read it in infinite loop. I see two possible ways to fix this. I have to investigate consequences to other parts of the code more to decide better one. ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
URL: http://gna.org/bugs/?20003 Summary: Security advisory Project: Freeciv Submitted by: prlw1 Submitted on: Sun Jul 29 18:41:34 2012 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: 2.3.2 Discussion Lock: Any Operating System: None Planned Release: ___ Details: I came across http://aluigi.altervista.org/adv/freecivet-adv.txt and a quick look at packet.c suggests that the code in 2.3.2 is the same as in the advisory. My attempts at querying the bug database haven't returned anything, so is this still news? ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Follow-up Comment #1, bug #20003 (project freeciv): is this still news? Yes. It would be nice if those who already invest so much time to investigate security and write advisories would bother to inform us too so that these things would get also fixed. Fix for A] for S2_3, S2_4 and TRUNK attached. This patch doesn't apply to S2_2, but security fix is still worth backporting (will check also S2_0 in case warclient folks will update their fork) (file #16241) ___ Additional Item Attachment: File name: CheckMinTotalPacketLen.patch Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20003] Security advisory
Update of bug #20003 (project freeciv): Planned Release: = 2.0.11, 2.2.8, 2.3.3, 2.4.0, 2.5.0 ___ Follow-up Comment #2: - Fix for A], S2_2 and S2_0 version. (file #16242) ___ Additional Item Attachment: File name: CheckMinTotalPacketLen-S2_2.patch Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?20003 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
