Menu
▾
▴
[ bzflag-Bugs-544300 ] kill message segfault (possibly malicious)
|
From: <no...@so...> - 2002-04-30 22:09:22
|
Bugs item #544300, was opened at 2002-04-15 19:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=103248&aid=544300&group_id=3248 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Trowbridge (davidtrowbridge) Assigned to: Tim Riker (timriker) Summary: kill message segfault (possibly malicious) Initial Comment: This -may- be malicious - i am not sure yet, but i only experienced it whilst dealing with a cheater, so who knows This seems to be a problem with MsgKilled The stack trace reveals this: #0 0x403b58d1 in __kill () from /lib/libc.so.6 #1 0x403b564d in raise (sig=11) at ../sysdeps/posix/raise.c:27 #2 0x0806c6ee in dying (sig=11) at playing.cxx:311 #3 <signal handler called> #4 ShotPath::getFlag (this=0x0) at ShotPath.h:175 #5 0x08070217 in handleServerMessage (human=1 '\001', code=27500, msg=0xbfffe4b2) at playing.cxx:1605 #6 0x08071ba6 in doMessages () at playing.cxx:2080 #7 0x08077008 in playingLoop () at playing.cxx:3598 #8 0x0807adde in startPlaying (_display=0x80ef068, renderer=@0xbffff500, _resources=@0x80ea960, _info=0x80ea800) at playing.cxx:4711 #9 0x0808e3d3 in main (argc=1, argv=0xbffffa94) at bzflag.cxx:1137 #10 0x403a3306 in __libc_start_main (main=0x808b230 <main>, argc=1, ubp_av=0xbffffa94, init=0x804b7b0 <_init>, fini=0x80d5e30 <_fini>, rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xbffffa8c) at ../sysdeps/generic/libc-start.c:129 The problem appears to be when shot is NULL in this call: switch (shot->getFlag()) Indicating its probably a problem with getting killed by a nonexistant shot. A possible fix (untested) is to drop a conditional around the switch statement, checking if shot is NULL. If so, it just prints a default message. ---------------------------------------------------------------------- >Comment By: Frank Thilo (chestal) Date: 2002-05-01 00:09 Message: Logged In: YES user_id=48940 I'm not really sure when it occurs and when not. But IMHO the new kill messages are flawed conceptually. The problem is that they try to detect the cuase of the kill by usign the shot id that is included in MsgKill. However, previous to MsgKill, the victim sends a MsgEndShot message. Thus, the shot in question is already expired when the Kill message arrives. I am not 100% sure how expired shots are handled in the ShotPath code, but obviously at some time after the shot is set as expired, the object might be destroyed or replaced by another shot (a salt value seems to be used to be able to distinguish between different shots). So, at least what can happen is that the shot in question is already deleted, thus no information about the kill cause is available. I don't know if other malicous things can happen when the shot is already replaced by a new one. The easiest fix would be to just use a default kill message when the shot cannot be found. However, I feel that usign the expired shot information is not a good idea anyway. It would be ok, if the Kill message contained the cause (flag), liek it will probably be in 1.8. For now, I'd recommend reverting to the plain old messages. Furthermore, some people do not like the new messages. Ok, they're fancy, but they make it much harder to see the essental information at a glance. Especially the name of the killer is harder to see as he is no longer at the end of the message. ---------------------------------------------------------------------- Comment By: David Trowbridge (davidtrowbridge) Date: 2002-04-15 22:12 Message: Logged In: YES user_id=66583 Its possible that steamroller is another cause of this segfault but it IS being used maliciously. I had perfect cell try to exploit this against me (after I added the check) on my flagless CTF server ---------------------------------------------------------------------- Comment By: Tim Riker (timriker) Date: 2002-04-15 22:08 Message: Logged In: YES user_id=8134 This happens when someone is killed by SteamRoller. I posted one fix, but it is not complete. ---------------------------------------------------------------------- Comment By: David Trowbridge (davidtrowbridge) Date: 2002-04-15 21:43 Message: Logged In: YES user_id=66583 This is definitely an error that does not come up in normal play and is therefore a malicious exploitation. It is fixable via checking whether the shot ID is equal to -1 Patch coming soon ---------------------------------------------------------------------- Comment By: David Trowbridge (davidtrowbridge) Date: 2002-04-15 20:13 Message: Logged In: YES user_id=66583 this workaround does not work correctly - currently examining ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=103248&aid=544300&group_id=3248 |