Bug 65372 (CVE-2005-0178)

<!-- SBZ_reproduce  -->
n/a

Created attachment 28091 [details]
setsid-tty-locking

Pavel, 
 
can you please review this patch to see whether it breaks anything, 
and if this is indeed what is in mainline ATM? 
 
If the patch is good, please commit it to all kernel branches for 
the next security update. That would be 
 
kernel-source-26:  SLES9_SP1, SLES9_SP2, SL92, HEAD 
kernel-source:     SLEC8, SL82, HEAD 
 
The vulnerability this is supposed to fix is CAN-2005-0178; see 
http://cve.mitre.org. 

Security problem with priority=Minor... "Interesting". I'm by no means tty
expert (and I fear that my try to commit to 7 different branches would result
with at least 5 of them broken).

I did a small investigation, and it seems to be the same solution as in current
linus's bk.

I'm sorry, I will not be able to do this one.

I'm on quite a slow link, and for some strange reason, getting SLES9_SP2_BRANCH\
takes >4hours (it is not yet done). It is not even saturating GPRS link. Just
\getting those 6 repositories (I already have HEAD) would take few days :-(.

[I did cp -a of HEAD, then update -r SLES9_SP2_BRANCH. Perhaps I should have
do\ne update from empty tree?]

back to okir to find some other developer...  

Not so quick, please :) 
 
I think Pavel is working on improving his connectivity right now. 
Correct me if I'm wrong. 

Handing over to Karsten who was just volunteered. 

Created attachment 34500 [details]
correct patch

The patch was incomplete, for sys.c the tty.h was missing.

Hmm, do you really want to back it to SLES9, this will be a major change,  
in SLES9 kernel no tty_sem exist, so we have to backport the complete  
tty stuff, not only this extention of using the semaphore. 
 
I didn't look at 2.4 based kernel yet, but I think that these need a big  
backport too.  
  
For 9.2 the patches are ready now, but need some testing, mbuilds are done.   

i would appreciate an evaluation by you on how critical security or bugwise 
this is for our customers. 
 
if this is just a rare race condition  and/or not exploitable secuzrity wise 
i have now problems to leave this as a "fix in stable" problem 

I simple do not know enough about the tty stuff to do such a evaluation, 
this is also my issue to fix it for the old releases, tty code is spread 
all over the kernel, not only in driver/char/tty, so it is difficult to find a 
correct patchset without breaking something. 
 
I still evaluate the changes in the tty stuff from SLES9 -->9.3 and try to 
isolate a patch. 
 
I also do not have any idea, how security relevant this is. 
 

OK, it seems that a backport for SLES9 is not too intrusive. I already have a 
patch, but it would be the best if someone else can review it. 

Created attachment 34570 [details]
patch for SLES9 SP1

I have tested the patch with SP2 beta1 and see no problems related to tty, I 
also have a backport for 2.4 ready. 
But I still do not understand enough about tty to make real tests, e.g. 
test the securety issue or stress test the locking, I only test if I can still 
login and logout. 
 
So anybody else should decide how we are going further. 
 

Seems we got stuck again. What does this patch protect against? What kind of 
nasty thing is possible if this patch is missing? 

This is my problem too, I have no idea how to test the patches and I also do 
not know, how to trigger the problem which should be fixed by this stuff. 
The URL from comment #3 was also not helpful in this matter (or I'm to stupid 
to find the correct place). 

since we are not comfortable with this fix  
and it has only minor implications (if any at all)  
  
I think we can have this fixed via upstream in later kernel versions.  
  
So my decision: fixed in STABLE.   

CVE-2005-0178: CVSS v2 Base Score: 6.2 (AV:L/AC:H/Au:N/C:C/I:C/A:C)