Phillip Pi <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 26 Aug 2006 10:55:25 -0700:
> NVIDIA poster told me to collect logs in my NVIDIA forum thread. I gathered > the newsgroup thread > datas: > > The newsgroup threads (not even reading a thread -- just the list) > that crashes are (copied and pasted): > Subject: > =?ISO-8859-1?Q?Cablebox_->DVD._Later_DVD->MP4_using_Handbrake_Mpeg-4_Video_/_AAC_Audio_,_FFMEG,_400kpbs_AVB,_2-pass_encoding,_22050_Sample_Rate,_128kbps_Bitrate.=0D=0DParts_3_and_4.=0D=0Dhttp://www.hbo.com/docs/programs/whentheleveesbroke/index.html=0D=0D=0D=0DThis_intimate,_heart-rending_portrait_of_New_Orleans_in_the_wake_of_the_destruction_tells_the_heartbreaking_personal_stories_of_those_who_endured_this_harrowing_ordeal_and_survived_to_tell_the_tale_of_misery,_despair_and_triumph._=0D=0DThe_film_also_looks_at_a_community_that_has_been_through_hell_and_back,_surviving_death,_devastation_and_disease_at_every_turn._Yet,_somehow,_amidst_the_ruins,_the_people_of_New_Orleans_are_finding_new_hope_and_strength_as_the_city_rises_from_the_ashes,_buoyed_by_their_own_resilience_and_a_rich_cultural_legacy._=0D=0D"New_Orleans_is_fighting_for_its_life,"_says_Lee._"These_are_not_people_who_will_disappear_quietly_-_they're_accustomed_to_hardship_and_slights,_and_they'll_fight_for_New_Orleans._This_film_will_showcase_the > From: spike > Newsgroups: alt.binaries.ipod.videos.movies > Date: Thu, 24 Aug 2006 08:02:33 -0700 > > I think that ISO thing is making it my whole X server crash hard. Is Pan > supposed to read this correctly? It could be (making it crash). Old-pan did handle strange encodings, but had a few bugs (or at least one, but irritating as it could cause crashes) in the way it did it. That's the worst known crashing issue it had (altho the scaling issues were well known and are dealt with in new-pan, but those didn't cause crashes). I've suspected that was what it was, but wanted to verify or at least narrow it down before I made that claim. That is in fact one of the reasons I have been pushing new-pan hard, lately, is because AFAIK it doesn't have the problem, at least with crashing, that old-pan did on strange language headers. (New-pan doesn't always interpret them, sometimes leaving them as iso-whatever in the subject or from column, tho it seems to do OK on the body with appropriate language headers, but I've not seen it crash.) The thing about crashes (in general, not pan specifically), particularly in C and C++ programs, is that crashes fairly often mark possible exploits, at least on x86 with its lack of solid memory protection, as many of those crashes are reading past the end of a buffer or other such memory errors. If an attacker can initialize that memory with malware instructions, it's often possible to get the program to execute them instead of crashing. While the malware would execute with the permissions of the person running the program (unless it's SUID/SGID), not as root (unless you are running it as root), that's bad enough. Luckily, user targeted applications on Linux aren't commonly malware targeted yet, with the possible semi-exception of browsers, so it's not a huge problem, but it's a serious problem none-the-less. I do /not/ like crashes in my internet enabled programs, particularly when they are dealing with untrusted internet served data! In addition, the weird data causing the crashes in pan is just the sort of thing that would be expected to cause exactly this type of major security issue buffer overruns -- unexpected 8-bit or even multi-byte data in a place where 7-bit ascii data is likely to be assumed. This crash has therefore bothered me every since I realized what was apparently causing it, and I've been rather glad new-pan seems more stable in that regard. Now, it should also be said that there are ways to "crash safely", and that pan and the libraries it uses may very well be coded to do so. I'm not a C/C++/assembly coder nor do I know all that much about "hardening" a system using memory buffer canaries (tho I do know the general technique is to put a pattern in the memory immediately after such a buffer, and after use of the buffer, check that pattern to see if it's changed, the safety zone and the pattern in it then being the canary) or the like, to be able to read pan's code (and that of its libraries) and know if this is a real security vuln or not. However, there's certainly a possibility that it is, as there is with any such crashes, particularly on unexpected data. Anyway, um... are you sure you want to keep running it now? Of course, one thing you could do is create a new user and group, set the pan executable to that user and group and SUID/SGID, and make that group relatively unprivileged so it can't read any of the private stuff on your system and /certainly/ can't overwrite anything but its own stuff. That's the general technique used for various system daemons and the like, particularly internet exposed ones. You could even run it in a chroot if you are that concerned about the crashes. Anyway... I went ahead and got the newshosting account and am busy setting it up and catching up on stuff now. Anybody that might have wished to sponsor me and get a bit of free money off of newshosting, too late now! =8^P I haven't gotten to that group yet, but I get tonite (Sat) off work for the first time in awhile, and unless they call me in, that's when I'm planning to check on that group. I still have old-pan installed too, so can see how it behaves in both versions. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
