Perhaps it's time to post this on Bugtraq?
Printable View
Perhaps it's time to post this on Bugtraq?
MsM, I'm not sure about that. First I thought: yes, post it on bugtraq! but on the other side, RedHat always respond very very quickly to emails. If I email friday night, they answer monday morning. If I email with a question they answer immediatly, they added me to the bug tracking system, so I can see 'my bug' and the progress they make in fixing it. So they are working on it. And making efforts to fix it, but the fix did not make it into RH9, that's a pity. I don't think it's necessary to put it on bugtraq yet.
from bugtaq faq:
So I think we could extend the deadline?Quote:
If they contact you asking for more time consider extending the deadline in good faith. If they continually fail to meet the deadline post to the list.
Did you ever get a reply on this subject? I haven't noticed any updates for it recently, but maybe I missed something. I still haven't seen the tcpdump updates that streamer mentioned either.
ConsummatumEst, I got replies from redhat when I mailed to them, they added the vulnerability to their bugzilla list with severity: security.
But like I posted before they did not got it fixed for version 9
Invictus, good point, however I can not agree completly.Quote:
Originally posted here by iNViCTuS
I do see what you are talking about because I was able to recreate the problem myself, however, I did notice that the only way this works is if you re-login as the same user that just logged off w/root priviliges.
This leads me to believe that it was done intentionally on the basis that if a user had superuser access before, why wouldn't he/she be able to have it again. I don't think that this "vulnerability" is as big of a risk as having the whole "key thing" in the first place.
You say that the user with the normal user account is also the same as the superuser, so it's no real problem? right. Ok this is true. I see your point.
There are however still a lot of situations where this could be exploited, for instance:
Some examples:
- You have a user with problems, the superuser comes to fix them, he does not log in in the gui but uses the 'key thing', and logs out, tada the normal user has superuser with his account.
- A network-admin goes to check the server, at this server let's say the account of an operator is logged in. This account is powerless but he needs it to print stuff, change backups,... so the admin uses the key thing and logs out, cause he thinks: "hey don't leave your account open, you stupid operator, everyone can access your stuff", doing this the 'smart' admin gives his/her account away to the 'stupid' operator.
You are right when saying the 'key thing' is a risk, specially when the default mode is 'keep authorisation' and they use a very bad pam_timestamp.
Note: Redhat did not leave it intentionaly cause they agreed with me that it is a security problem related to the pam_timestamp for the authorisation tool. Normaly one would expect that a normal user can not log in keeping superuser powers from a previous session (IMHO), I know in most cases it's probably the same person having two accounts, but in those other cases. We are 4 months later and they still have no fix, while redhat 9 is vulnerable too.
I promised to keep you all updated,
well, Redhat found a fix for the bug, basically its as follows :test if the timestamp is older than oldest login of the requesting user and if it is, the access is denied.
so with the next RHEL updates this fix is probably included.
Therefor the updated versions of RHE are going to have the fix.
What about the Fedora product?
Fedora is Redhat's red-headed stepchild. I doubt redhat themselves will incorporate the patch, though they may hand the fix off to the Fedora maintains.Quote:
I hope they will, I do not run Fedora myself so I can't test it by now. Next week I'm going to change a few boxes overhere (2 new mobo's, cpu's, mem, hdds comming this way :) ) So perhaps I will try Fedora on one of those or on an older one.
Is the authorisation 'key' in the tray concept also available in Fedora? If it is then Fedora is also vulnerable. I hope they will hand it over to the open source communicty for Fedora.
I hope the RH enterprise edition will have the fix with the next updates like an employer from Redhat assigned to the problem suggested.
Maybe they should release RedHat 10 and do it like they did with every version of RedHat and let people download it and use it without having to buy that Corporate ****.
It's sort of Sad to see RedHat Desktop software costing MORE than SUSE Linux Enterprise Server.
RedHat has never been on my good side really, I hated RHN. Having to sign up for an account and things like that just to get updates..... No other distro makes you do that and I hated it. They should dump that ****, even Windows doesn't make you have an account.
Fedora Core 1 was crap. The updates were slow to download and it sucked. Fedora Core 2 was a little better, and 3, well, I'm still not sure. I installed it last night and so far I can't even use my Mouse.... I'm still testing. I still don't know why RedHat charges so damned much.
SUSE Linux Enterprise Server 9, would cost me around 400 dollars. This would let me install from a GUI over SSH and or a VPN. Meaning I don't even have to get up. And that feature only needs 256 MBs RAM. So as long as you have 256 MBs RAM, you can install it over SSH or a VPN. Talk about NICE. And it's cheaper than the Desktop versions of RedHat. I don't even want to get into the Server side of RedHat, it's eXPensive.