| 00:51.02 | *** join/#bzflag Marzipan (~Marzipan@sign-4db606ab.pool.mediaWays.net) |
| 01:41.52 | *** join/#bzflag ahs3- (~ahs3-@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 02:05.17 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 03:40.16 | *** join/#bzflag Flash (~jwmelto@c-76-25-208-148.hsd1.co.comcast.net) |
| 03:40.16 | *** join/#bzflag Flash (~jwmelto@bzflag/developer/Flash) |
| 03:47.24 | *** join/#bzflag jeffm (~jeffm@76.167.236.199) |
| 03:47.28 | *** join/#bzflag jeffm (~jeffm@unaffiliated/jeffm2501) |
| 03:47.28 | *** mode/#bzflag [+v jeffm] by ChanServ |
| 04:08.28 | blast007 | jeffm: I wasn't having luck getting the nVidia drivers working in Linux, but I might try again tomorrow. |
| 04:08.40 | jeffm | ahh |
| 04:09.11 | blast007 | dunno if it's just cuz the card is so new, or if Ubuntu just blows |
| 04:12.13 | blast007 | open-source driver can barely run the UI, much less BZFlag (insta-crash when trying to run bz), and with the proprietary driver loaded it wouldn't bring up the unity |
| 04:20.08 | sussudio | i remember bzflag running fine on bzflag about 5 years ago... using a radeon aiw |
| 04:24.11 | jeffm | you can try mint, ubuntu less suck |
| 04:27.25 | jeffm | linux support is overtated |
| 04:28.03 | jeffm | it doesn't even support metro |
| 04:40.08 | *** join/#bzflag jeffm (~jeffm@unaffiliated/jeffm2501) |
| 04:40.08 | *** mode/#bzflag [+v jeffm] by ChanServ |
| 04:41.52 | Flash | Jeff, I need to start over trying to build on Mac. What is the state of the current Xcode project? |
| 04:42.27 | jeffm | same as it was before |
| 04:42.34 | jeffm | aka not useable |
| 04:49.44 | jeffm | I believe that the last build was made using the old way by hacking up a system to build like it used to |
| 05:15.07 | *** join/#bzflag Deadalot (~philb@71.55.20.159) |
| 05:59.22 | Flash | it shows calling joinGame from nboUnpackString.. don't see how that can happen |
| 06:00.02 | Flash | stupid client.. reviewing: here is an odd stack trace from apocalypse: http://flash.pastebin.ca/2262418 |
| 06:01.18 | Flash | so I'm thinking memory corruption |
| 06:01.40 | Flash | but it's really hard to test on this new machine until I can make it build |
| 06:03.37 | jeffm | yeah we have come to the memory corruption conclusion as well |
| 06:03.49 | jeffm | all the stack traces are atop late |
| 06:03.58 | jeffm | too late |
| 06:04.10 | Flash | I found a potential memory overrun in playing, but I don't want to check it in without SOME testing |
| 06:04.18 | Flash | at LEAST a compile, for crying out loud |
| 06:04.29 | jeffm | what dod you find? |
| 06:05.15 | Flash | http://flash.pastebin.ca/2262419 |
| 06:05.44 | Flash | it's possible for the server to send a string longer than the client can accept |
| 06:06.06 | jeffm | sure, that looks like a safe thing to check in |
| 06:06.12 | jeffm | how would the server send it tho? |
| 06:06.23 | jeffm | we'd want to fix it there |
| 06:07.32 | Flash | my strong suspicion is that the team switch plugin is sending something, and I don't have any insight into what that is doing |
| 06:08.06 | jeffm | what message is sending it? |
| 06:08.11 | Flash | don't know |
| 06:08.32 | jeffm | we should probably protect the pack as well |
| 06:08.52 | Flash | I do know that they disable the team switch for a while and it was pretty stable |
| 06:09.45 | jeffm | still the plugin doesn't send a message directly, it has to call an API that eventually does the pack |
| 06:09.52 | jeffm | so we should protect that pack |
| 06:12.27 | Flash | the packs appear to be length agnostic. The vulnerability is in the client unpacking to a fixed length buffer |
| 06:13.06 | jeffm | we should not pack a string into a fixed size buffer |
| 06:13.28 | Flash | haven't proved that yet, but we are Unpacking to a fixed size buffer |
| 06:13.30 | jeffm | fixed size buffers should have fixed sized strings :) |
| 06:13.49 | jeffm | hmm |
| 06:14.27 | jeffm | well you are closer then anyone else |
| 06:14.35 | jeffm | just infall a real OS and you'll be fine :) |
| 06:15.03 | Flash | ok, we ARE packing to a fixed length buffer |
| 06:15.45 | jeffm | then we should just check to make sure that the message we get is the right size |
| 06:20.19 | jeffm | what API function does team change call that may be sent with a bad length? |
| 06:20.33 | Flash | I have no idea |
| 06:20.53 | Flash | Since my stack trace is dealing with corrupted memory, there's no reason to trust it at all |
| 06:21.19 | jeffm | there is no reason to trust any code at that point :) |
| 06:21.37 | Flash | I searched for all the unpackString calls, and the most likely offender I can think of is a URL that could be long (but longer than 1k?) |
| 06:22.13 | jeffm | make the packer not accept a string longer then 1 k |
| 06:23.32 | Flash | actually, it needs to be a bit less, because the protocol includes some binary data in every message, so not all strings can be the max length |
| 06:24.00 | jeffm | ok, "some limit" :) |
| 06:24.14 | jeffm | there are no real valid reasons to send data that large |
| 06:24.51 | jeffm | Different OSs have different max packet sizes too |
| 06:25.10 | Flash | rather than a static memory area, it would be better to use a std::vector<char> and size it as required to pack and unpack |
| 06:25.37 | jeffm | byte not char but yes a dynamic buffer is better, slower but better |
| 06:25.53 | Flash | is "byte" a type? |
| 06:25.54 | jeffm | you'd want to preallocate in chunks |
| 06:26.02 | jeffm | it should be |
| 06:26.13 | jeffm | char is signed, you want the unsigned one, there is a ubyte_8 I think |
| 06:26.14 | Flash | it didn't use to be |
| 06:26.28 | jeffm | IIRC it was added in one of the C++ revs |
| 06:26.35 | jeffm | unsigned char would work too |
| 06:26.54 | Flash | probably 0X (which is just now becoming more widely available) |
| 06:27.12 | jeffm | you mean 11 |
| 06:27.16 | jeffm | but no it was before that IIRC |
| 06:27.54 | Flash | in any event, I'm not messing with anything until I get an environment where I can do minimal testing. |
| 06:28.12 | jeffm | it should be fixable with out redoing the entire message buffer system |
| 06:28.20 | jeffm | optimally we want this to be a server fix |
| 06:28.30 | jeffm | even if that means cutting off some messages |
| 06:28.52 | Flash | I agree that the server shouldn't send anything the client isn't expecting but the client should protect itself as well |
| 06:29.07 | jeffm | sure, both ends should be secured |
| 06:29.32 | jeffm | optimally we'd have a buffer class that was used on both sides that never let it do an overrun |
| 06:29.44 | jeffm | and it could then dynamically allocate what it needed on pack and read |
| 06:31.03 | jeffm | I helve the c identifier for a byte is uint8_t |
| 06:31.07 | jeffm | fyi :) |
| 06:31.58 | jeffm | added in c99 |
| 06:31.58 | Flash | that's not really a type; it's a typedef |
| 06:32.09 | jeffm | sure |
| 06:32.18 | jeffm | that you can use like a type |
| 06:32.22 | jeffm | hence the 'def' ;) |
| 06:32.24 | Flash | agreed |
| 06:32.47 | jeffm | and it's always the same size on all bitnesses |
| 06:33.13 | jeffm | IIRC int can be 64 bits on itaiium 64 and some other rare platforms |
| 06:33.36 | Flash | int is explicitly undefined length, but char is not |
| 06:33.53 | jeffm | yeah, the only prob with char is it's signed |
| 06:34.09 | jeffm | tho no mater what you are casting at some point |
| 06:34.17 | Flash | as far as allocating a byte of memory, the sign doesn't matter |
| 06:34.22 | jeffm | yeah |
| 06:34.29 | jeffm | just makes some of it harder to read in the debuger |
| 06:34.42 | Flash | and there is most certainly casting aplenty in the messaging |
| 06:34.53 | jeffm | yeah a class would be best |
| 06:34.59 | jeffm | then it'd protect itself on both ends |
| 06:35.03 | jeffm | that's how I've always done it |
| 06:35.15 | jeffm | it cold also build up large messages from multiple packets |
| 06:36.18 | Flash | I'll take another tilt at Xcode, perhaps tomorrow. Or, I might even fire up this old PC and try to get linux on it |
| 06:36.47 | jeffm | bootcamp your mac :) |
| 06:37.02 | jeffm | the new Xcode project needs a huge amount of work |
| 06:37.10 | jeffm | then existing one just calls the command line stuff |
| 06:38.37 | jeffm | I believe the only way to get the command line stuff to build is use an old OS/xcode or hack up your machine to include/use the tools/libs that are missing |
| 07:09.40 | *** join/#bzflag jeffm (~jeffm@cpe-76-167-236-199.socal.res.rr.com) |
| 07:09.41 | *** join/#bzflag jeffm (~jeffm@unaffiliated/jeffm2501) |
| 07:09.41 | *** mode/#bzflag [+v jeffm] by ChanServ |
| 07:40.54 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
| 07:50.44 | blast007 | sussudio: bzflag runs fine on linux. it's just that linux doesn't run fine. ;) |
| 07:51.50 | blast007 | X was crashing just from opening/closing windows |
| 07:55.27 | sussudio | blast007: X isn't linux |
| 07:55.57 | blast007 | oh, are you gonna be one of 'those people' that is all "linux is only the kernel!" |
| 07:56.02 | sussudio | well, neither is the OS. |
| 07:56.45 | sussudio | blast007: i actually had the kernel keep running for a month when everything else segfaulted due to a cpu and a psu fan having failed... i only noticed when the pc case got really really hot |
| 07:56.51 | blast007 | cuz I could just say that the kernel driver is foobar and making the graphics subsystem crash |
| 08:11.45 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 08:29.08 | blast007 | sussudio: so what should I call it then? GNU/Linux/X ? ;) |
| 08:29.40 | sussudio | and whatever dist you're running it on |
| 09:28.33 | *** part/#bzflag alezakos (~kongr45gp@unaffiliated/alezakos) |
| 09:28.33 | *** join/#bzflag alezakos (~kongr45gp@unaffiliated/alezakos) |
| 12:08.27 | *** join/#bzflag bier_ (~bier@p5085ECAF.dip.t-dialin.net) |
| 12:08.36 | *** join/#bzflag bier (~bier@p5085ECAF.dip.t-dialin.net) |
| 12:16.19 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 13:01.46 | *** join/#bzflag lvlinux (~n1gg@c-50-147-64-9.hsd1.tn.comcast.net) |
| 14:18.25 | *** join/#bzflag sirquine (~quine@c-76-120-71-113.hsd1.co.comcast.net) |
| 15:21.33 | *** join/#bzflag ahs3- (~ahs3-@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 17:04.59 | *** join/#bzflag jeffm (~jeffm@cpe-76-167-236-199.socal.res.rr.com) |
| 17:04.59 | *** join/#bzflag jeffm (~jeffm@unaffiliated/jeffm2501) |
| 17:04.59 | *** mode/#bzflag [+v jeffm] by ChanServ |
| 19:01.33 | *** join/#bzflag swigg__ (~swigg@nsc69.38.101-238.newsouth.net) |
| 19:03.31 | *** join/#bzflag meeba (~lamer@c-75-71-180-64.hsd1.co.comcast.net) |
| 20:24.35 | *** join/#bzflag mmadia (~mmadia@pdpc/supporter/active/mmadia) |
| 21:09.11 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 21:24.05 | *** part/#bzflag mmadia (~mmadia@pdpc/supporter/active/mmadia) |
| 21:49.53 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 23:05.53 | *** join/#bzflag catay (~smertens@kaiya.catay.be) |