Bug 981522 - sessreg Module experiences buffer overflow at high UID
Summary: sessreg Module experiences buffer overflow at high UID
Status: RESOLVED FIXED
: 862583 (view as bug list)
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: X.Org (show other bugs)
Version: 13.2
Hardware: i586 Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Egbert Eich
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-25 06:47 UTC by Hennig Reinhard
Modified: 2016-06-07 07:28 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Source file (16.08 KB, patch)
2016-05-26 05:32 UTC, Hennig Reinhard
Details | Diff
Patch. (423 bytes, patch)
2016-05-26 19:37 UTC, Egbert Eich
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hennig Reinhard 2016-05-25 06:47:16 UTC
xdm and kdm crash when UID beyond 10.000.000 are used. Some UIDs provide stable logins but some don't. For example 20.000.000 works fine, 25.000.000 fails. You can provoke the error by make a simple account like this in your /etc/passwd file:
otto:x:25000107:25000000:Testuser lokal:/opt/home/otto:/bin/bash

kdm and xdm crash, while terminal based login and graphical logins using gdm work fine. 

This account in your /etc/passwd works fine:
willi:x:20000107:20000000:Testuser lokal:/opt/home/willi:/bin/bash

reason for that behaviour is a buffer overflow in this module: sessreg 

used by xdm and kdm.

It doesn't depend on the source (/etc/passwd or ldap).

You may check by doing 

sessreg -a willi # works, returns no error

sessreg -a otto # returns error:
seeking lastlog entry: Invalid argument

Other Scenarios: Yes: Login using gdm displaymanager is not affected
Fix: choose different UIDs or gdm

Fast help would be appreciated.
Comment 1 Egbert Eich 2016-05-25 09:11:50 UTC
(In reply to Hennig Reinhard from comment #0)
 
> Fast help would be appreciated.

Henning, I'm sorry, there won't be fast help for this I'm afraid.

This is openSUSE, everything here is pretty much 'best efford'. openSUSE is free software: Ttere is a saying in the free software world: 'everybody gets to scratch his own back'.
 
This means two things:
1. since the code is open and you are allowed to modify it, you are able to fix things yourself. Nothing will be in your way. You may even share your changes with others and provide them to the upstream project. If your patch is correct and the project accepts it, you have two advantages: 
  a. it will work in future versions as well.
  b. you may have helped others.
2. since free software is mostly done by volunteers, there is no one who has an obligation to help you, so unless someone else's back itches the same way yours does, chances are you will have to fix it yourself.

This boils down to: if you want a fix fast, you will have to do it yourself. 
If you have a patch, you are welcome to provide it here and we can help you by reviewing it and making sure it gets back to the upstream project. 

If you are patient and can wait, someone will come to it eventually and look into it.
Comment 2 Stefan Dirsch 2016-05-25 09:32:13 UTC
Also you appear to have mixed up UID with GID. The format in passwd is

...:UID:GID:...

So you're talking about GID here. When you played around with GID, did you make sure a group with this GID did exist?

I couldn't easily reproduce the issue with sessreg. Neither on Leap 42.1, nor with the sessreg binary of openSUSE 13.2. I suggest to debug this issue with gdb.
Comment 3 Hennig Reinhard 2016-05-25 09:51:34 UTC
Sorry, 
these are the correct values (id -a):

uid=25000107(otto) gid=25000000(hno) Gruppen=25000000(hno)

uid=20000107(willi) gid=20000000(goe) Gruppen=20000000(goe)

sessreg -a otto
seeking lastlog entry: Invalid argument

As I mailed, we are working in it. Reason for that trouble: multiplying high values with unexpected value. sessreg 1.7 on OpenSuSE 12.2 works fine:

# cat /etc/SuSE-brand
openSUSE
VERSION = 12.2

# sessreg -a otto
# sessreg -a willi

No faults
Comment 4 Hennig Reinhard 2016-05-26 05:32:36 UTC
Created attachment 678405 [details]
Source file

Buffer overflow by multiplying high values
Comment 5 Stefan Dirsch 2016-05-26 10:45:44 UTC
Why did you attach the c source file for sessreg?

You mean one would need to use lseek64 instead of lseek? Feel free to give it a try ...
Comment 6 Hennig Reinhard 2016-05-26 13:09:14 UTC
Hi indeed, we experienced a fatal crash at login from kdm with UIDs
beyond 10.000.000 e.g. 25.000.0000.

llseek and lseek are not suitable for working through extremely large files.

lseek64 is a need!
Comment 7 Egbert Eich 2016-05-26 19:37:02 UTC
Created attachment 678553 [details]
Patch.

For reference, I've been in contact with Reinhard Henning regardin this.
He gave me the Sign-off:

Signed-off-by: Herbert Kütz <herbert.kuetz_at_ofd-z.niedersachsen.de>

I will check if we should do an autotool test for the presence of llseek64(), prepare the patch and update the package for openSUSE.
Comment 8 Stefan Dirsch 2016-05-28 09:46:12 UTC
Hmm. So Reinhard Henning is Herbert Kütz? I've found three lseek() calls in the sources. Also lseed64() manual page tells me one needs a

  #define _LARGEFILE64_SOURCE 

before 

  #include <sys/types.h>

So no Reviewed-by from my side at this moment. ;-)
Comment 9 Egbert Eich 2016-05-28 10:35:46 UTC
I believe found a lightly different way to fix this problem: largefile support is already included, ie autoconf checks for it and makes the adjustments needed, however the code doesn't use them.
I'd need someone to test this though. Reinhard, could you please run:
'zypper ar http://download.opensuse.org/repositories/home:/eeich:/branches:/OBS_Maintained:/sessreg/openSUSE_13.2_Update/home:eeich:branches:OBS_Maintained:sessreg.repo'
on a machine which exhibits this problem, run
'zypper update sessreg'
and follow the instructions?
Please let me know if this also fixes the problem. Thanks!
Comment 10 Egbert Eich 2016-05-28 10:41:55 UTC
(In reply to Stefan Dirsch from comment #8)
> Hmm. So Reinhard Henning is Herbert Kütz? I've found three lseek() calls in

Reinhard has contacted my by email, I've only added the information releant to this ticket here. The developer who found the fix for the problem at hand was Herbert Kütz.

> the sources. Also lseed64() manual page tells me one needs a
> 
>   #define _LARGEFILE64_SOURCE 
> 
> before 
> 
>   #include <sys/types.h>
> 
> So no Reviewed-by from my side at this moment. ;-)

This may be done already thru some header. For convenience there is an autoconf macro which takes care of it. This macros has been used already however it was useless as the code still used casts to long. 
With this macro it should be fine to use off_t and lseek() as it checks for any needed compiler flags so that these can deal with 'largefiles'.
I've fixed all occurrences of lseek() in my test package.
Comment 11 Egbert Eich 2016-05-29 22:17:33 UTC
I've tested the patch now. It is in fact only needed on 32-bit systems as on 64-bit ones all types are big enough.
I've pushed the fix upstream, 
submitted it to Facroty: SR# 398703
and did maint updates for 13.2 and Leap 42.1: MR#398799.
Comment 12 Bernhard Wiedemann 2016-05-29 23:00:17 UTC
This is an autogenerated message for OBS integration:
This bug (981522) was mentioned in
https://build.opensuse.org/request/show/398799 13.2+42.1 / sessreg
Comment 13 Swamp Workflow Management 2016-06-06 10:08:43 UTC
openSUSE-RU-2016:1499-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 981522
CVE References: 
Sources used:
openSUSE Leap 42.1 (src):    sessreg-1.1.0-3.1
openSUSE 13.2 (src):    sessreg-1.0.8-4.3.1
Comment 14 Wolfgang Bauer 2016-06-06 11:59:28 UTC
*** Bug 862583 has been marked as a duplicate of this bug. ***
Comment 15 Egbert Eich 2016-06-07 07:28:16 UTC
There should be an update for sessreg available for openSUSE 13.2 since yesterday.

Reinhard, thanks for the investigation and tracking this down! It helped a lot and sped up getting a fix. 

Meanwhile I've also pushed the fix into X.Org. 

Thanks again!