[Pan-users] Re: Pan v0.14.2.91 crashing X hard (black screen)/messing up NVIDIA card badly...

[Duncan]

Phillip Pi <address@hidden> posted
address@hidden, 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