lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <1D2F5E73-1AA6-11D8-905B-000A95DA4200@kagi.com> From: rixstep at kagi.com (rixstep@...i.com) Subject: Vulnerability in Terminal.app > This sounds more like an issue with sudo than terminal. Have you > tested to see if sudo displays the same behaviour on other machines? Yes, it is an issue with sudo. It occurs when using Terminal. I ran the text by Apple and they were OK with this description. I understand the title seems misleading, but the text is not. I've tried it on three. I don't intend to try it on more. That's Apple's job, and they seem to be working on it. >> This has been tested on two Apple PowerBook G4 laptops and with >> operating systems OS X 10.2.3 Jaguar, OS X 10.2.7 Jaguar, and OS X >> 10.3 >> Panther. The exploit works on all machines with all operating systems. > > Isn't that a rather broad generalization from two machines and three > versions of the same operating system? No. You misread. It means 'the exploit works on all the machines with all the operating systems cited'. It's been done on an iBook too, BTW. But there's code at the bottom, which should explain it. Did you read the code? No? > 4. Change your sudo settings to require a password each time you use > it: > > timestamp_timeout > Number of minutes that can elapse before sudo will ask > for > a passwd again. The default is 5. Set this to 0 to > always > prompt for a password. If set to a value less than 0 > the > user's timestamp will never expire. This can be used > to > allow users to create or delete their own timestamps > via > sudo -v and sudo -k respectively. Yes, of course. I didn't want to get that drastic, as the interval is a convenience not everyone wants to give up. But yes, this is good too. :) >> The Code >> -------- >> The weak link would seem to be in this snippet of the sudo source. > > Have you also reported this to the authours of sudo[0]? Apple are responsible for this, what I know. If they want to get anyone else involved, they will. And perhaps already have. I just want to make sure people know what's going on and see Apple make a fix. It's their Unix, and their business, not mine. Besides, we don't know yet if it's the sudo code. Again, I refer to the snippet I reproduced. It's the call to time which is screwing up. Perhaps one should in such case refer it to the authors of time? But it's a laptop problem - it might apply to other OSes and other boxes, but that's for every user to see. Unless someone wants to fund me a lot of laptops to test this ridiculous thing. Apple have to make sure /etc/sudoers is wiped out on a sleep. When you close the lid on a *Book, the thing goes immediately to sleep and doesn't touch a thing. If you let the machine be and it decided on sleep itself, your 5 minutes will normally expire first. So there doesn't have to be anything wrong with sudo. And there doesn't have to be anything wrong with time. After all, didn't 'ken' say 'keep your hands off the drivers'? > cheers! > [0] http://www.courtesan.com/sudo/ > ======================================================================= > === > "A cat spends her life conflicted between a deep, passionate and > profound > desire for fish and an equally deep, passionate and profound desire to > avoid getting wet. This is the defining metaphor of my life right > now." Dag-tag. R.
Powered by blists - more mailing lists