Re: Backport of the integer overflow in the brk system call
On Tue, Dec 09, 2003 at 11:45:58PM +1100, Russell Coker wrote: As for acting like a Jackass, the Johnny Knoxville and his colleagues are very talented entertainers who work hard. I wouldn't compare them to you in any way. Oh, I dunno. I got *your* attention. But chill the hell out. I'm disengaging. My point (such as it is) is accomplished. Nothing but technical matters from me from here on. Save the bitching for next time.
Re: Backport of the integer overflow in the brk system call
On Tue, 9 Dec 2003 22:52, Tom [EMAIL PROTECTED] wrote: On Tue, Dec 09, 2003 at 01:12:13AM +, Colin Watson wrote: . Could you please try to keep debian-devel posts to well-thought-out [1] technical content, Sure. I'd also ask everyone to keep their anti-American, anti-Bush SIGs and random comments out of both lists. I have acted like a jackass on purpose -- to give you a taste of what it feels like to put up with incessant opinions which you find illogical. How about a cease-fire on both sides of the idological debate? There is no idological debate, there is no side that you are claiming to be against. I don't recall any messages in this thread that were anti-USian (*) or anti-Bush. As for acting like a Jackass, the Johnny Knoxville and his colleagues are very talented entertainers who work hard. I wouldn't compare them to you in any way. (*) I don't recall anyone writing anything on this list that could be anti-central-America, anti-south-America, or anti-Canada. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backport of the integer overflow in the brk system call
On Dec 8, 2003, at 07:14, Julian Mehnle wrote: Apart from that, as soon as the use of IPv6 broadens, dynamically assigned IP addresses will diminish. Stateless autoconfig + privacy extensions means quite the opposite is likely to occur.
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 09, 2003 at 01:12:13AM +, Colin Watson wrote: . Could you please try to keep debian-devel posts to well-thought-out [1] technical content, Sure. I'd also ask everyone to keep their anti-American, anti-Bush SIGs and random comments out of both lists. I have acted like a jackass on purpose -- to give you a taste of what it feels like to put up with incessant opinions which you find illogical. How about a cease-fire on both sides of the idological debate? But I decided to cut down on the opinion posts; these are just reverberations from people catching up.
Re: Backport of the integer overflow in the brk system call
On Sun, Dec 07, 2003 at 09:16:58PM -0500, Patrick Ouellette wrote: Instead of a smartcard/token/whatever physical device, this incident could possibly have been thwarted by requiring developers to pre-register their machine with the project (using ssh host key for example). The attacker would have the user's account information, but project machines would have refused access since the host id did not match the user's registered hosts. Then the project machine could have alerted both the project's admin team and the owner of the compromised account. Given that the easiest way to get a developer's password is to compromise a machine that person logs into Debian systems from, I doubt this well help that much. :-) The only exception I can see would be if the user uses the same password for his/her Debian account and some other system, and the attacker is smart enough (read: wants to go specifically after Debian) to test that password on d.o as well. /* Steinar */ -- Homepage: http://www.sesse.net/
RE: Backport of the integer overflow in the brk system call
Russell Coker wrote: On Mon, 8 Dec 2003 13:16, Patrick Ouellette [EMAIL PROTECTED] wrote: Instead of a smartcard/token/whatever physical device, this incident could possibly have been thwarted by requiring developers to pre-register their machine with the project (using ssh host key for example). The attacker would have the user's account information, but project machines would have refused access since the host id did not match the user's registered hosts. Then the project machine could have alerted both the project's admin team and the owner of the compromised account. One problem with this is developer's machines that are on dial-up Internet connections. In the case of such machines you can verify the host key but not the IP address. You cannot verify the IP address *exactly*, but you can verify whether the IP address lies within a range. Dial-up users could at least register a certain address range, so as to vastly mitigate the attack risk. Apart from that, as soon as the use of IPv6 broadens, dynamically assigned IP addresses will diminish. But this still leaves the issue of how to deal with dial-up machines. Even if we restrict connections to a single ISP as often dial-up machines are not used with multiple machines, this still isn't necessarily much good, some dial-up ISPs have 50,000 IP addresses. Still, IP address (even if it's a range, not a single address) verification vastly mitigates the attack risk. Finally, if the attacker can compromise the machine and the machine is online (EG permanently connected machines) there's no good options. What's more secure, no good options, or no good options plus IP address verification, even if range-based? Some attack vectors one will never be able to protect against, but it still makes sense to protect against other vectors, doesn't it?
Re: Backport of the integer overflow in the brk system call
On Mon, 8 Dec 2003 23:14, Julian Mehnle [EMAIL PROTECTED] wrote: One problem with this is developer's machines that are on dial-up Internet connections. In the case of such machines you can verify the host key but not the IP address. You cannot verify the IP address *exactly*, but you can verify whether the IP address lies within a range. Dial-up users could at least register a certain address range, so as to vastly mitigate the attack risk. Apart from that, as soon as the use of IPv6 broadens, dynamically assigned IP addresses will diminish. That will work in some situations, but not in all. If a DD is visiting the Netherlands they may use a zonnet.nl dial-in (Zon is one of the biggest Dutch ISPs and a likely choice). Zon had over 10,000 phone lines in Amsterdam last time I checked (not sure if it has increased or decreased since then). Amsterdam also has many skillful hackers (most ethical, but I'm sure there are some black hats too). So in this situation (which is not very hypothetical given the number of DD's who visited me when I lived in Amsterdam) the DD would get random IP addresses from the same pool as the attacker. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
RE: Backport of the integer overflow in the brk system call
Russell Coker wrote: On Mon, 8 Dec 2003 23:14, Julian Mehnle [EMAIL PROTECTED] wrote: You cannot verify the IP address *exactly*, but you can verify whether the IP address lies within a range. Dial-up users could at least register a certain address range, so as to vastly mitigate the attack risk. Apart from that, as soon as the use of IPv6 broadens, dynamically assigned IP addresses will diminish. That will work in some situations, but not in all. True. But even though it might not prevent *all* attacks, it will prevent *many*, without incurring additional costs or adding considerable complexity to the Debian Developer apparatus, will it not?
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 03:29:02PM -0800, Tom wrote: Just rambling... I'm sure there's tons of holes in what I just said. All this rambling is getting pretty damn tedious as I try to read through two weeks' worth of debian-devel backlog. Could you please try to keep debian-devel posts to well-thought-out [1] technical content, excluding rambling, musings on the sociology of the American South, and other such noise, please? This is not debian-user, not that noise is good there either with an even more rampantly enormous backlog to deal with. [1] Quiet down, you cynics in the peanut gallery. :) -- Colin Watson [EMAIL PROTECTED]
Re: Backport of the integer overflow in the brk system call
On Mon, Dec 08, 2003 at 01:28:20PM +1100, Russell Coker wrote: Another problem is that host keys require SUID ssh client in the default configuration. This hasn't been true since OpenSSH 3.3, and therefore since before woody. See ssh-keysign(8). openssh (1:3.3p1-0.0woody1) testing-security; urgency=high [...] * Support setuid ssh-keysign binary instead of setuid ssh client. [...] -- Daniel Jacobowitz [EMAIL PROTECTED] Mon, 24 Jun 2002 13:43:44 -0400 Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 11:55:26AM -0800, Tom wrote: instance is the hacker sniffed the password, and then logged on to Debian's servers later at his leisure from a different PC. With a Instead of a smartcard/token/whatever physical device, this incident could possibly have been thwarted by requiring developers to pre-register their machine with the project (using ssh host key for example). The attacker would have the user's account information, but project machines would have refused access since the host id did not match the user's registered hosts. Then the project machine could have alerted both the project's admin team and the owner of the compromised account. The initial compromise would have been detected sooner, and project machines protected *without* any additional hardware or money being spent. -- Patrick Ouellette [EMAIL PROTECTED] [EMAIL PROTECTED] Amateur Radio: KB8PYM
Re: Backport of the integer overflow in the brk system call
On Mon, 8 Dec 2003 13:16, Patrick Ouellette [EMAIL PROTECTED] wrote: On Thu, Dec 04, 2003 at 11:55:26AM -0800, Tom wrote: instance is the hacker sniffed the password, and then logged on to Debian's servers later at his leisure from a different PC. With a Instead of a smartcard/token/whatever physical device, this incident could possibly have been thwarted by requiring developers to pre-register their machine with the project (using ssh host key for example). The attacker would have the user's account information, but project machines would have refused access since the host id did not match the user's registered hosts. Then the project machine could have alerted both the project's admin team and the owner of the compromised account. One problem with this is developer's machines that are on dial-up Internet connections. In the case of such machines you can verify the host key but not the IP address. Therefore if the machine is cracked then the host key can be stolen and the machine impersonated. Another problem is that host keys require SUID ssh client in the default configuration. This is bad in that a ssh client can potentially be used to crack the machine, and it can potentially be used to steal the host key. If we change ssh to be setgid not setuid for host based authentication then things will be marginally improved. But another thing that should be done is to have ssh support for the host key used for host-based authentication not being the same as that used for incoming ssh connections. But this still leaves the issue of how to deal with dial-up machines. Even if we restrict connections to a single ISP as often dial-up machines are not used with multiple machines, this still isn't necessarily much good, some dial-up ISPs have 50,000 IP addresses. Finally, if the attacker can compromise the machine and the machine is online (EG permanently connected machines) there's no good options. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Authentication enhancements (was Re: Backport of the integer overflow in the brk system call)
On Mon, Dec 08, 2003 at 01:28:20PM +1100, Russell Coker wrote: But this still leaves the issue of how to deal with dial-up machines. Even if we restrict connections to a single ISP as often dial-up machines are not used with multiple machines, this still isn't necessarily much good, some dial-up ISPs have 50,000 IP addresses. Your other very good points not withstanding, I was thinking along the lines of the user's id substituting for the ip address in the verification process. User authentication would require a matched user id host id or a warning would be triggered. I didn't claim it was a perfect solution, I don't even claim it as a *good* solution. It would be another layer of checks in the authentication process, with the benefit of not costing much in terms of money. Finally, if the attacker can compromise the machine and the machine is online (EG permanently connected machines) there's no good options. That is true for many of the suggested additions. Once a trusted machine is compromised, it's game over. My suggestion would only send up a flag if the attacker attempted to access project machines from a host the user had not registered (assuming he did not know enough to steal the host's key first). If we could tie the host key to a unique property of the physical host it would help. In any event, I think there is merit in requiring a user / host authentication pair if we can come up with a method of tying the host key to the hardware. I would be willing to work on such a task, if others also think it might have merit. -- Patrick Ouellette [EMAIL PROTECTED] [EMAIL PROTECTED] Amateur Radio: KB8PYM
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 05:19:22PM -0800, Tom wrote: Smartcards would have avoided the Debian compromise: merely having a compromised DD box would have prevented bad guy from getting on the box. It's all about layers of defense. I think the DD's should seriously think about requiring smartcards. It would have prevented the proxmiate cause of our recent troubles. You must be joking. If the developer's system is compromised, and he logs into another system after that time, that system can be easily compromised also. -- - mdz
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 02:23:54PM -0500, Matt Zimmerman wrote: On Tue, Dec 02, 2003 at 05:19:22PM -0800, Tom wrote: You must be joking. If the developer's system is compromised, and he logs into another system after that time, that system can be easily compromised also. Yes, but the reason it would have been efficiacious in this *particular* instance is the hacker sniffed the password, and then logged on to Debian's servers later at his leisure from a different PC. With a smartcard, he would have had to done it *on* the Dev's infected PC *while* the smartcard was plugged in. In theory the smartcard would not be plugged in all the time, thus diminishing the attack surface.
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 11:55:26AM -0800, Tom wrote: Yes, but the reason it would have been efficiacious in this *particular* instance is the hacker sniffed the password, and then logged on to Debian's servers later at his leisure from a different PC. With a smartcard, he would have had to done it *on* the Dev's infected PC *while* the smartcard was plugged in. In theory the smartcard would not be plugged in all the time, thus diminishing the attack surface. Not really; he just has to set things up ahead of time. This is like claiming the attacker has to be present in order to sniff your password from a telnet session (he doesn't; he just has to have been around at any time before then in order to set up a sniffer). -- - mdz
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 06:13:49PM -0500, Matt Zimmerman wrote: Not really; he just has to set things up ahead of time. This is like claiming the attacker has to be present in order to sniff your password from a telnet session (he doesn't; he just has to have been around at any time before then in order to set up a sniffer). That's totally true. It's not the way this attack happened though. All I know is it's a layer and experts say layered defense is best. I still think it would discourage the cracker. A lot of the open a netcat over the exposed pipe tricks wouldn't work iff the smartcard auth stack wasn't compromised -- the netcat couldn't get auth'd, and the server wouldn't buy it. The problem now is a pipe is a pipe. Just rambling... I'm sure there's tons of holes in what I just said.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 02:57:11AM +0100, Bernd Eckenfels wrote: On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: The only way to have avoided this kernel vulnerability from day-0 of discovery/fix release would have been to be constantly upgrading to pre-release kernels. Yes but also the debian servers would not have been vulnerable if they had used 2.4.23. At least not at that point in time. They also would not have been affected if they were running 2.2.x. Why don't we just downgrade them all, then? -- gram signature.asc Description: Digital signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Tue, 02 Dec 2003, Tom wrote: Yes but the attacker did not steal the DD's computer. He rooted it remotely. So the machine is rooted remotely, the DD logs into a debian box even using our new fangled smart cards, and the attacker still can control the connection. In this particular intrusion vector, the use of a smart card merely means that the attacker has to trojan the ssh binary on the compromised machine and use it to run a command that opens a shell under the DD's uid on a non-privledged port, thus circumventing the smart card in its entirety. If you log into a machine from a compromised machine using any means I can forsee today, the attacker can always control the account of the machine logged into, because the attacker effectively become the user of the machine. Don Armstrong -- Tell me something interesting about yourself. Lie if you have to. -- hugh macleod http://www.gapingvoid.com/archives/batch20.php http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 12:20:59AM -0800, Don Armstrong wrote: On Tue, 02 Dec 2003, Tom wrote: Yes but the attacker did not steal the DD's computer. He rooted it remotely. So the machine is rooted remotely, the DD logs into a debian box even using our new fangled smart cards, and the attacker still can control the connection. Not while the smart card isn't inserted. In this particular intrusion vector, the use of a smart card merely means that the attacker has to trojan the ssh binary on the compromised machine and use it to run a command that opens a shell under the DD's uid on a non-privledged port, thus circumventing the smart card in its entirety. I don't understand this objection, but it seems valid. Could you explain? If you log into a machine from a compromised machine using any means I can forsee today, the attacker can always control the account of the machine logged into, because the attacker effectively become the user of the machine. Yes, I always warned my employer that all I have to do is own your machine before you plug in your smart card, leave a logic bomb to do something while you're connected, wait for you to hang up and then report back. But it's all layers, layers, layers. More layers = better, none is a panacea. Have you ever used smartcards? I think that the more layers the better.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
[NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into private mail, but your e-mail address was munged in some sort of anti-spam measure, and not trivially un-mungeable. Please consider providing information on how to demunge it in some X- header, or not using munging at all.] On Wed, 03 Dec 2003, Tom wrote: On Wed, Dec 03, 2003 at 12:20:59AM -0800, Don Armstrong wrote: the attacker still can control the connection. Not while the smart card isn't inserted. Well, the DD can't log in without the smart card, so that's clearly a prerequisite. the use of a smart card merely means that the attacker has to trojan the ssh binary on the compromised machine and use it to run a command that opens a shell under the DD's uid on a non-privledged port, thus circumventing the smart card in its entirety. I don't understand this objection, but it seems valid. Could you explain? If you have adjusted ssh, you don't need to show the compromised user the output of all the commands that are being run on the other end of the connection. Have you ever used smartcards? Unfortunatly, yes. I think that the more layers the better. Sure, I'm just saying that the cost to put 1000 smart cards with the requisite hardware in all of the places that DD's log in from doesn't give us enough extra security to merit the extra cost. Of course, if someone was to design such a system, work all of the bugs out, and get a hardware vendor to deploy it to DD's, I wouldn't stand in the way. [I would personally rather see paired random number generators than smart cards, but we're a bit too spread out for that to be much of a reality.] Don Armstrong -- You could say she lived on the edge... Well, maybe not exactly on the edge, just close enough to watch other people fall off. -- hugh macleod http://www.gapingvoid.com/batch8.htm http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:03:16AM -0800, Don Armstrong wrote: [NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into private mail, but your e-mail address was munged in some sort of anti-spam measure, and not trivially un-mungeable. Please consider providing information on how to demunge it in some X- header, or not using munging at all.] Heh. That's my actual email address. Fooled ya. Well, the DD can't log in without the smart card, so that's clearly a prerequisite. You leave it unplugged until you need it, do your thing, then unplug it. Sure, I could still infect your toolchain so you unwittingly upload trojaned stuff. But the fact is in this *actual* compromise the password was stolen and the hacker worked later at his leisure: smartcards would have prevented this *actual* incident (but of course doesn't prohibit other ways of attack). If something could have prevented something that actually happened, I say go for it.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote: If something could have prevented something that actually happened, I say go for it. Oh, one last thing: each DD should pay for the device him/her self and should be required to fly to meet wherever they can pick them up. Why do you assume somebody has to pay for everything? What's wrong with bearing some of the costs yourself? This is a big deal.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 02:00:51PM +1100, Russell Coker wrote: I agree that smartcards would help a lot. However as has been previously suggested the cost of 1200+ smart-card readers is probably prohibitive. What about RSA tokens? This solution does not require any special hardware to connect on the client side. Cheers Artur
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, 03 Dec 2003, Tom wrote: each DD should pay for the device him/her self and should be required to fly to meet wherever they can pick them up. Why do you assume somebody has to pay for everything? What's wrong with bearing some of the costs yourself? Could it possibly be because equipment is expensive and plane flights around the planet are not cheap? I know few DDs who are independently wealthy, and frankly, requiring volunteers to spend large amounts of money so they can volunteer their time isn't something that we should be doing, nor do I really see the project as a whole supporting such an action. Please feel free to produce code and take action to prove me wrong though. Don Armstrong -- UF: What's your favourite coffee blend? PD: Dark Crude with heavy water. You are understandink? If geiger counter does not click, the coffee, she is just not thick. http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Backport of the integer overflow in the brk system call
On Wed, 3 Dec 2003 20:34, Artur R. Czechowski [EMAIL PROTECTED] wrote: On Wed, Dec 03, 2003 at 02:00:51PM +1100, Russell Coker wrote: I agree that smartcards would help a lot. However as has been previously suggested the cost of 1200+ smart-card readers is probably prohibitive. What about RSA tokens? This solution does not require any special hardware to connect on the client side. What is a RSA token? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 09:49:21PM +1100, Russell Coker wrote: On Wed, 3 Dec 2003 20:34, Artur R. Czechowski [EMAIL PROTECTED] wrote: On Wed, Dec 03, 2003 at 02:00:51PM +1100, Russell Coker wrote: I agree that smartcards would help a lot. However as has been previously suggested the cost of 1200+ smart-card readers is probably prohibitive. What about RSA tokens? This solution does not require any special hardware to connect on the client side. What is a RSA token? Device used in some internet banks. You have a device, which has only chipset, digital pad with on/off switch and display, all embedded in small case. Authentication is made using C/R algorithm: you receive a number from system, enter it into token, chipset signs it using stored RSA key, you get a number from display and use is as a password. Cheers Artur -- [...] jestem wredna, elazna mapa /Croolik/
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 05:19:22PM -0800, Tom wrote: On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: On Wed, Dec 03, 2003 at 11:17:19AM +1100, Russell Coker wrote: The only way to have avoided this kernel vulnerability from day-0 of discovery/fix release would have been to be constantly upgrading to pre-release kernels. I'm starting to sound like I'm trolling for closed-source development models or something, which is not the case, Smartcards would have avoided the Debian compromise: merely having a compromised DD box would have prevented bad guy from getting on the box. Perhaps. But smartcards have a significant problem in a project such as Debian: Are you going to pay for all those smartcards plus their readers? Including any smartcards for possible future DD's? If not, I suggest we forget about this, as it won't be feasible. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 12:06:33PM +0100, Artur R. Czechowski wrote: What is a RSA token? Device used in some internet banks. You have a device, which has only chipset, digital pad with on/off switch and display, all embedded in small case. Authentication is made using C/R algorithm: you receive a number from system, enter it into token, chipset signs it using stored RSA key, you get a number from display and use is as a password. Yeah, these are good: they're cheap and I think it would have been effective at preventing this particular incident. That's an excellent idea.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 12:10:28PM +0100, Wouter Verhelst wrote: Are you going to pay for all those smartcards plus their readers? Including any smartcards for possible future DD's? If not, I suggest we forget about this, as it won't be feasible. I don't think the USB models cost that much (maybe $50-$100 ea. in bulk). My badge at Microsoft was my smart card. The devs themselves could pay part of the cost, with perhaps partial donations from a corporate sponsor. I think even a college student could find $50 for this. The other guys suggestion about RSA tokens was better. I think they are probably only $15-$25, because they don't connect to your PC. Anyway, feel free to forget about it. It was just a suggestion.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 12:06:33PM +0100, Artur R. Czechowski wrote: What is a RSA token? Device used in some internet banks. You have a device, which has only chipset, digital pad with on/off switch and display, all embedded in small case. Authentication is made using C/R algorithm: you receive a number from system, enter it into token, chipset signs it using stored RSA key, you get a number from display and use is as a password. The RSA SecurID tokens are a bit smarter than that; the output for a given input changes every minute. My employer uses them for remote access to their intranet; you have a fixed pin number which you enter into the card to get this minute's (6 digit) password. No reason why the pin would have to be fixed though. I have no idea what they cost. Also the newest ones are not exactly fit for carrying around in your wallet. They last 3 years on internal batteries. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Backport of the integer overflow in the brk system call
On Wed, 3 Dec 2003 22:27:39 +1100, Hamish Moffatt [EMAIL PROTECTED] wrote: The RSA SecurID tokens are a bit smarter than that; the output for a given input changes every minute. My employer uses them for remote access to their intranet; you have a fixed pin number which you enter into the card to get this minute's (6 digit) password. No reason why the pin would have to be fixed though. I have no idea what they cost. Also the newest ones are not exactly fit for carrying around in your wallet. They last 3 years on internal batteries. I seriously doubt that the server-side software is DFSG-free. The only Linux Agent that is available from rsa.com is for RedHat 7.3, and I would be astonished if it were available in source code form. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Backport of the integer overflow in the brk system call
On Wed, 3 Dec 2003 23:06, Marc Haber [EMAIL PROTECTED] wrote: I have no idea what they cost. Also the newest ones are not exactly fit for carrying around in your wallet. They last 3 years on internal batteries. I seriously doubt that the server-side software is DFSG-free. The only Linux Agent that is available from rsa.com is for RedHat 7.3, and I would be astonished if it were available in source code form. For an initial order of 1200 units and the potential for other larger orders they may reconsider this. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 01:06:08PM +0100, Marc Haber wrote: On Wed, 3 Dec 2003 22:27:39 +1100, Hamish Moffatt [EMAIL PROTECTED] wrote: The RSA SecurID tokens are a bit smarter than that; the output for a given input changes every minute. My employer uses them for remote access to their intranet; you have a fixed pin number which you enter into the card to get this minute's (6 digit) password. No reason why the pin would have to be fixed though. I have no idea what they cost. Also the newest ones are not exactly fit for carrying around in your wallet. They last 3 years on internal batteries. I seriously doubt that the server-side software is DFSG-free. The only Linux Agent that is available from rsa.com is for RedHat 7.3, and I would be astonished if it were available in source code form. That's true, but there may be similar technology available from other companies. I have no idea what the server-side part looks like, having only been an end user of the token solution. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote: On Wed, Dec 03, 2003 at 01:03:16AM -0800, Don Armstrong wrote: [NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into private mail, but your e-mail address was munged in some sort of anti-spam measure, and not trivially un-mungeable. Please consider providing information on how to demunge it in some X- header, or not using munging at all.] Heh. That's my actual email address. Fooled ya. How about including your full name somewhere in your posts too then? I find it a bit off-putting to discuss security with someone who's obscuring their identity. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Thu, Dec 04, 2003 at 12:20:57AM +1100, Hamish Moffatt wrote: How about including your full name somewhere in your posts too then? I find it a bit off-putting to discuss security with someone who's obscuring their identity. Ha Ha Ha what a joke. I don't want to be googled for all eternity. Let me tell you a story about a job I had one time: I worked for a guy (in his basement -- don't ask) who bought your personal credit card data and other publicly available information. He would pay about $10,000 or $15,000 for lists of ~100,000-200,000 people's data. My job was to datamine it under criteria like: Give me all the people who make between $50,000-$80,000 /yr, own a boat, live within 15 miles of certain area, and used their Visa more than 10 times on the boat within the last 6 months. We'd rank order the data, apply the filter, and maybe get 10,000 good names, which he would sell for about $140,000 to a home alarm company, who would then call you during dinner. [1] Another job I had was for a drug testing company. My job was to write the report processing system which would say You Person X have Tested Positive for Drugs A, B, and C and you are fucked. At one point in 1994 I had 40,000 people's drug test results on my 486SX-50. Just for grins I did a group by query, grouping drug frequency by a company's SIC industry code, and sorting in descending order. The most frequent people to test positive for drugs are construction workers, marijuana and cocaine. The next most frequent are school employees (probably bus drivers) testing positive for alcohol. Everything else was kind of evenly distributed. And you wonder why I am concerned with my identity!!! [1] I finally told the guy to go pound sand. I said: You'd be more useful to society if you just grow corn or something. Doing that type of work made me want to slit my wrists.
Re: Backport of the integer overflow in the brk system call
On Thu, 4 Dec 2003 00:19:36 +1100, Hamish Moffatt [EMAIL PROTECTED] wrote: On Wed, Dec 03, 2003 at 01:06:08PM +0100, Marc Haber wrote: I seriously doubt that the server-side software is DFSG-free. The only Linux Agent that is available from rsa.com is for RedHat 7.3, and I would be astonished if it were available in source code form. That's true, but there may be similar technology available from other companies. I have no idea what the server-side part looks like, having only been an end user of the token solution. I have only taken a perfunctory look at the web site, and the server-side looks like a PAM plugin for the RSA product. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:24:50AM -0800, Tom wrote: On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote: If something could have prevented something that actually happened, I say go for it. Oh, one last thing: each DD should pay for the device him/her self and should be required to fly to meet wherever they can pick them up. Why do you assume somebody has to pay for everything? What's wrong with bearing some of the costs yourself? Hahahahahahahaha Share the crack. plonk -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 08:45:49AM -0600, Steve Langasek wrote: Share the crack. In my experience kids in college and right out tend to freak out over the thought of having to spend a few dollars of disposable income, because they don't have any :-) Hey, laugh if you want, most organizations have dues, it's not unprecedented in human history :-)
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 05:42:20AM -0800, Tom wrote: Let me tell you a story about a job I had one time: I worked for a guy (in his basement -- don't ask) who bought your personal credit card data and other publicly available information. He would pay about $10,000 or $15,000 for lists of ~100,000-200,000 people's data. My job was to datamine it under criteria like: Give me all the people who make between $50,000-$80,000 /yr, own a boat, live within 15 miles of certain area, and used their Visa more than 10 times on the boat within the last 6 months. We'd rank order the data, apply the filter, and maybe get 10,000 good names, which he would sell for about $140,000 to a home alarm company, who would then call you during dinner. [1] So you've aided telemarketers and worked for Microsoft? Is your last name Darkness, middle name Prince of? -- gram signature.asc Description: Digital signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 09:06:07AM -0600, Graham Wilson wrote: So you've aided telemarketers and worked for Microsoft? Is your last name Darkness, middle name Prince of? Satan fell because he wanted to know. So do I. I'm a contrarian. I believe the opposite of whatever I'm confronted with at the moment. Evil is when you look around your life and say: man, I gotta get some new friends. :-)
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 01:54:22PM +1100, Matthew Palmer wrote: Nov 28 22:39 Linux 2.4.23 released ^ Bernd is correct, though - if the machines had been running 2.4.23, they wouldn't have been vulnerable. The fact that it was impossible to do so doesn't enter into the equation when you're working from blind assertions. g Hehe, well I am sorry. I had the impression 2.4.23 was older. Should have checked my facts. BTW: I do have checked the kernel version of the major distros, all ship newer kernels than debian (if you look at the upstream version). However I do not know how reliable dostrowatch is, for comparision. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Backport of the integer overflow in the brk system call
* Russell Coker ([EMAIL PROTECTED]) [031203 04:03]: I have sent a message to Werner asking if the GPG smart-card device could be re-implemented with a USB interface. I think that a USB dongle with GPG technology would be a good option as most developer's machines already have USB support. as discussed in depth in an earlier c't magazine (german) usb is not a save bus to use for security relevant applications, since it allows for recording and backplaying of command sequences.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
I demand that Tom may or may not have written... On Wed, Dec 03, 2003 at 08:45:49AM -0600, Steve Langasek wrote: Share the crack. In my experience kids in college and right out tend to freak out over the thought of having to spend a few dollars of disposable income, because they don't have any :-) Some of us have to *buy* them before we can spend them ;-) -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Oh, sarge too... This was the most unkind cut of all.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Tue, Dec 02, 2003 at 05:34:05PM -0800, Don Armstrong wrote: On Tue, 02 Dec 2003, Tom wrote: I think the DD's should seriously think about requiring smartcards. It would have prevented the proxmiate cause of our recent troubles. Smartcards are not a magical panacea either. The problems associated No, they're not. Security is all about layers of defense. with them aren't too terribly different from those associated with keys or other forms of physical security, notably, that they can be stolen, or the output from them duplicated. Refer to the ongoing saga between DirectTV and satelite pirates for a trivially applicable example. Yes but the attacker did not steal the DD's computer. He rooted it remotely. It is true that a shitty smartcard which is only dumb storage for a private key is no better than storing your keys on an USB keyring. Good smartcards never transfer the key off the card. The smart card can be compromised itself true. Repeat: Security is about layers of defense. Multiple things have to be compromised. From my perspective, Smartcards do little to raise the bar. They merely move the bar sideways. You're wrong. They're better.
Re: Backport of the integer overflow in the brk system call
On Tue, 2 Dec 2003 23:46:45 +, Geoff Richards [EMAIL PROTECTED] said: On Tue, Dec 02, 2003 at 01:28:28PM -0800, Tom wrote: I read all the words but took a completely different meaning :-) I'm from the South, we have different speech patterns... South of where? The Mason-Dixon line? manoj -- Beware of all enterprises that require new clothes, and not rather a new wearer of clothes. Henry David Thoreau Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
RE: Backport of the integer overflow in the brk system call
Andreas Schuldei wrote: * Russell Coker ([EMAIL PROTECTED]) [031203 04:03]: I have sent a message to Werner asking if the GPG smart-card device could be re-implemented with a USB interface. I think that a USB dongle with GPG technology would be a good option as most developer's machines already have USB support. as discussed in depth in an earlier c't magazine (german) usb is not a save bus to use for security relevant applications, since it allows for recording and backplaying of command sequences. What article was that? Anyhow, a serial port or a PS/2 keyboard port is unsafe in the same way. A secure card reader solution would use a challenge/response procedure, so a simple replay attack could never be successful. Additionally, a secure card reader device would be sealed (and deactivate/destroy itself upon physical break-in) and require the user to enter a PIN/password to use the cryptographic key stored on the card. What would make such a card reader solution particularly unsafe when connected through USB?
Re: Backport of the integer overflow in the brk system call
On Wed, 3 Dec 2003 08:30:55 +0100, Bernd Eckenfels [EMAIL PROTECTED] said: Hehe, well I am sorry. I had the impression 2.4.23 was older. Should have checked my facts. BTW: I do have checked the kernel version of the major distros, all ship newer kernels than debian (if you look at the upstream version). However I do not know how reliable dostrowatch is, for comparision. Really? Prove it. Or is this fact like your other facts? manoj Package: kernel-image-2.6.0-test9-1-386 Priority: optional Section: base Installed-Size: 38132 Maintainer: Herbert Xu [EMAIL PROTECTED] Architecture: i386 Source: kernel-image-2.6.0-test9-i386 Version: 2.6.0-test9-1 Provides: kernel-image, kernel-image-2.6 Depends: initrd-tools (= 0.1.53), coreutils | fileutils (= 4.0), module-init-tools (= 0.9.13) Suggests: lilo (= 19.1), fdutils, kernel-doc-2.6.0-test9 Filename: pool/main/k/kernel-image-2.6.0-test9-i386/kernel-image-2.6.0-test9-1-386_2.6.0-test9-1_i386.deb Size: 13660416 MD5sum: 7734ca75e94f9d36f5993b58386e69a7 Description: Linux kernel image for version 2.6.0-test9 on 386. This package contains the Linux kernel image for version 2.6.0-test9 on 386, the corresponding System.map file, and the modules built by the packager. It also contains scripts that try to ensure that the system is not left in a unbootable state after an update. . If you wish to update a bootdisk, or to use a bootloader to make installing and using the image easier, we suggest you install the latest fdutils (for formatting a floppy to be used as boot disk), and LILO, for a powerful bootloader. Of course, both these are optional. . Kernel image packages are generally produced using kernel-package, and it is suggested that you install that package if you wish to create a custom kernel from the sources. -- It is bad luck to be superstitious. Andrew W. Mathis Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 10:34:13AM +0100, Artur R. Czechowski wrote: What about RSA tokens? This solution does not require any special hardware to connect on the client side. This also means it does not provide any additional security, besides the costs. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 12:03:52AM +1100, Russell Coker wrote: For an initial order of 1200 units and the potential for other larger orders they may reconsider this. There are some more tokens, which are baed on the open X9.9 DES protcol and not the secret SecureID stuff. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 10:18:44AM +1100, Russell Coker wrote: What about RSA tokens? This solution does not require any special hardware to connect on the client side. This also means it does not provide any additional security, besides the costs. What makes you think that? Well, I was talking about the no special hardware part. If you talk about hardware token, yes you are right. As I said before, secureid is most likely the worst solution you can use in an open project. (I asumed you mean RSA soft tokens) the resulting number be returned to the server. However ssh doesn't support custom prompts from the server, so the best we could do is to take a code from the device and append it to a password to send to the server. I think there is ACE support in SSHd, working with a timed challenge. OpenSSh with protocol 2 supports challenge response authentication like opie/skey which can also be used for X9.9 DES cards I guess. At least my FreeBSD router annoys me with such a server generated login challenge. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 11:42:06PM +0100, Bernd Eckenfels wrote: On Wed, Dec 03, 2003 at 10:34:13AM +0100, Artur R. Czechowski wrote: What about RSA tokens? This solution does not require any special hardware to connect on the client side. This also means it does not provide any additional security, besides the costs. Yes. But I suppose, that this solution is cheaper. I do not know a production's cost nor stock price, but one of Polish banks requires 200PLN (about 50USD) for every next token (first is included into product). Another one (German, operating in Europe) requires a half of it (about 25USD) for lost/damaged token. And ~9USD yearly fee for token, if not included in product. I do not know prices for smartcards/readers (I still mean about client's part, not server software) but maybe someone has data to compare? BTW, if some day Debian decide to use any method which requires a special device please consider about secure way to deliver this device to developer. Cheers Artur -- opady mgy i miasto ze snu si budzi, gra czmycha ju noc kto tam cicho czeka by kto powrci, do gwiazd jest bliej ni krok pies si wczy popod murami bezdomny, niesie si tsknota czyja na wiata cztery strony
Re: Backport of the integer overflow in the brk system call
On Thu, 4 Dec 2003 09:42, Bernd Eckenfels [EMAIL PROTECTED] wrote: On Wed, Dec 03, 2003 at 10:34:13AM +0100, Artur R. Czechowski wrote: What about RSA tokens? This solution does not require any special hardware to connect on the client side. This also means it does not provide any additional security, besides the costs. What makes you think that? Such a token uses a cryptoraphically secure algorithm to generate a new number every minute (or other reasonably small time period). If you don't have the token then you don't have one half of what is necessary to authenticate yourself and can't login. Some tokens just display a number, some require that some sort of pass (either a password or a code obtained from the server) be entered into the device and the resulting number be returned to the server. However ssh doesn't support custom prompts from the server, so the best we could do is to take a code from the device and append it to a password to send to the server. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backport of the integer overflow in the brk system call
On Thu, 4 Dec 2003 05:02, Andreas Schuldei [EMAIL PROTECTED] wrote: * Russell Coker ([EMAIL PROTECTED]) [031203 04:03]: I have sent a message to Werner asking if the GPG smart-card device could be re-implemented with a USB interface. I think that a USB dongle with GPG technology would be a good option as most developer's machines already have USB support. as discussed in depth in an earlier c't magazine (german) usb is not a save bus to use for security relevant applications, since it allows for recording and backplaying of command sequences. If the protocol for communication with the device is secure then this should not be a problem. If the protocol is bad then intercepting a different connection method is not going to be too difficult. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 02:57:11AM +0100, Bernd Eckenfels wrote: On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: The only way to have avoided this kernel vulnerability from day-0 of discovery/fix release would have been to be constantly upgrading to pre-release kernels. Yes but also the debian servers would not have been vulnerable if they had used 2.4.23. At least not at that point in time. Just because Debian doesn't have a time machine... There is simply no excuse! ;-) -- Brian May [EMAIL PROTECTED]
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 02:11:59PM +1100, Russell Coker wrote: Every DD needs to have immediate access to servers running each of the supported architectures. Yes of course. But this does not mean they have to have access to infrastructure of the project. A box for a DD to debug and test the builds is all which is required. Nothing important has to be installed. I understand, that the lack of hardware on some platforms may require the buildd for that platform run on the only debian box. However, I think it does not make fun to work on a buildd box, anyway. Especially not on those exotic architectures. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Backport of the integer overflow in the brk system call
Frederik Dannemare [EMAIL PROTECTED] wrote: just curious: any particular reason why we didn't see a backport any sooner of the integer overflow in the brk system call (see recent announcement by Wichert Akkerman: http://lists.debian.org/debian-security-announce/debian-security-announce-2003/msg00212.html) like we did with the ptrace issue some time back? Wasn't it (the brk vuln) considered to be threatening enough to justify a quick fix, or was it because the fix by Andrew Morton didn't say (kerne changelog) enough about the potential seriousness of the vuln, or? Apparently nobody knew it was comparable to ptrace, it looked like a simple bugfix and not like a local root exploit. | Robert van der Meulen managed to decrypt the binary which revealed | a kernel exploit. cu andreas
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 10:08:03AM +0100, Andreas Metzler wrote: Apparently nobody knew it was comparable to ptrace, it looked like a simple bugfix and not like a local root exploit. Well, I just downloaded 2.4.23 from kernel.org and installed it. [obGrumble] I never got hit by any of the Microsoft exploits either but I hated the upgrade treadmill [end]. Of course this is the 1st one in Linux for me and I'm willing to give y'all the benefit of the doubt 10 or 11 times :-) Was this problem a deviation from well-established security practices or is a new thing? Could somebody explain it in a nutshell?
Re: Backport of the integer overflow in the brk system call
Tom [EMAIL PROTECTED] wrote: On Tue, Dec 02, 2003 at 10:08:03AM +0100, Andreas Metzler wrote: Apparently nobody knew it was comparable to ptrace, it looked like a simple bugfix and not like a local root exploit. Well, I just downloaded 2.4.23 from kernel.org and installed it. You could have simply used the fixed 2.4.18 from security.debian.org. [...] Was this problem a deviation from well-established security practices or is a new thing? Afaict no and no. Could somebody explain it in a nutshell? Afaik: 2.4.23 contains literally 100s of changes, one of these was a small change to do_brk(), which looked like a normal non-critical bugfix to everybody involved. Some time later Debian was hacked and backtracing how the intruder got superuser privileges revealed that that the do_brk() without the small change was guilty, it had been no simple bug but a local privilege escalation issue. To repeat this: Neither Debian, nor Suse, nor Linux Kernel had known that there was a local root exploit in Linux Kernel 2.4.x (x23) until Debian was hacked *and* until Robert van der Meulen found out how the intruder managed to get root privileges on the hacked machines. Once the vulnerability was known at least Debian and RedHat (I don't read e.g. Suse's or Mandrake's security announces) released an advisory with fixed packages as fast as possible. Disclaimer: I am no member of the security team and was not involved in finding or fixing the bug. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 12:08:17PM +0100, Andreas Metzler wrote: Afaik: 2.4.23 contains literally 100s of changes, one of these was a small change to do_brk(), which looked like a normal non-critical bugfix to everybody involved. Some time later Debian was hacked and backtracing how the intruder got superuser privileges revealed that that the do_brk() without the small change was guilty, it had been no simple bug but a local privilege escalation issue. Thanks Andreas! My understanding is that the do_brk vulnerability allowed access to kernel address space. It seems a lot of work is needed to move from that freedoom to spawning a root shell. I'd be interested in seeing a worked example. -- Jon Dowland http://jon.dowland.name/
Re: Backport of the integer overflow in the brk system call
Jonathan == Jonathan Dowland [EMAIL PROTECTED] writes: Jonathan On Tue, Dec 02, 2003 at 12:08:17PM +0100, Andreas Metzler Jonathan wrote: Afaik: 2.4.23 contains literally 100s of changes, one of these was a small change to do_brk(), which looked like a normal non-critical bugfix to everybody involved. Some time later Debian was hacked and backtracing how the intruder got superuser privileges revealed that that the do_brk() without the small change was guilty, it had been no simple bug but a local privilege escalation issue. Jonathan My understanding is that the do_brk vulnerability allowed Jonathan access to kernel address space. It seems a lot of work is Jonathan needed to move from that freedoom to spawning a root Jonathan shell. I'd be interested in seeing a worked example. Actually I'm staring at the code for hours without much success about how to write anything in the kernel. It does not literally allow access to the kernel address space: if it does so, all you need to do is to traverse the kernel data structures to find where is the task_struct for the process itself and change the EUID to 0 in order to get root. What the bug gives is a memory region that extends through the kernel memory. The process cannot access that region: it is protected, and you can read it only in kernel mode. You cannot try to pass that as an address buffer to a system call either: system calls check whether address is past the end of process address space. So the program must somehow trick the kernel into accessing the region by itself, and since the kernel believes the correctness of the region it will not do any further checking. The only way that readily comes to mind is to let the program core dump: the kernel will most likely happily read all the kernel memory and save it into the core file. But it is still rather far from changing anything in the kernel memory. Andreas is definitely right that the hole doesn't look like that it is that dangerous. Regards, Isaac.
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: rather far from changing anything in the kernel memory. Andreas is definitely right that the hole doesn't look like that it is that dangerous. It messed up your life for a couple weeks. Jesus, it's not the end of the world, but that's the way Microsoft (used to | still) thinks. If it wasn't a big deal we wouldn't be talking about it. It shut down servers. It's dangerous enough.
Re: Backport of the integer overflow in the brk system call
Scripsit Tom [EMAIL PROTECTED] On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: rather far from changing anything in the kernel memory. Andreas is definitely right that the hole doesn't look like that it is that dangerous. If it wasn't a big deal we wouldn't be talking about it. It shut down servers. It's dangerous enough. Whw Isaac said was that he understands why the kernel developer who originally fixed the bug did not realize that it was security critical. -- Henning MakholmDetta, sade de, vore rena sanningen; ty de kunde tala sanning lika väl som någon annan, när de bara visste vad det tjänade til.
Re: Backport of the integer overflow in the brk system call
On Tue, 2003-12-02 at 17:31, Tom wrote: On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: rather far from changing anything in the kernel memory. Andreas is definitely right that the hole doesn't look like that it is that dangerous. It messed up your life for a couple weeks. Jesus, it's not the end of the world, but that's the way Microsoft (used to | still) thinks. If it wasn't a big deal we wouldn't be talking about it. It shut down servers. It's dangerous enough. Of course it is a dangerous hole. As you say that has already been shown. But the point was that it didn't _look_ dangerous when the bug was discovered. Had it looked dangerous, a security update would have been issued. /Jens
Re: Backport of the integer overflow in the brk system call
Tom [EMAIL PROTECTED] writes: On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: rather far from changing anything in the kernel memory. Andreas is definitely right that the hole doesn't look like that it is that dangerous. [snip] If it wasn't a big deal we wouldn't be talking about it. It shut down servers. It's dangerous enough. Note the looks like. -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Latein ist das humanoide quivalent zu Fortran. -- Alexander Bartolich in at.linux
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 08:51:50PM +0100, Andreas Rottmann wrote: Tom [EMAIL PROTECTED] writes: On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: rather far from changing anything in the kernel memory. Andreas is definitely right that the hole doesn't look like that it is that dangerous. [snip] If it wasn't a big deal we wouldn't be talking about it. It shut down servers. It's dangerous enough. Note the looks like. I read all the words but took a completely different meaning :-) I'm from the South, we have different speech patterns... the hole doesn't look like that it is that dangerous means something different than the hole doesn't look like that it is dangerous in my ears ... that is diminuitve in my dialect if you don't put emphasis on it :-)
Re: Backport of the integer overflow in the brk system call
Henning Makholm wrote: Scripsit Tom [EMAIL PROTECTED] On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: rather far from changing anything in the kernel memory. Andreas is definitely right that the hole doesn't look like that it is that dangerous. If it wasn't a big deal we wouldn't be talking about it. It shut down servers. It's dangerous enough. Whw Isaac said was that he understands why the kernel developer who originally fixed the bug did not realize that it was security critical. OK, this is sort of what I was after. I suspected this was the case, since nothing else would make much sense. I'm just glad the exploit was discovered, and I think the way the whole situation was handled from day one was very professional. -- B/R, Frederik Dannemare
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 10:08:03AM +0100, Andreas Metzler wrote: Apparently nobody knew it was comparable to ptrace, it looked like a simple bugfix and not like a local root exploit. What bugs the hell out of me is that people with nothing better to do with their time can sit on the lkml and watch what's getting fixed, and put more analysis into individual fixes than the kernel maintainers themselves can, and cook up an exploit for what all and sundry previously believed to be reasonably benign. I love the bazaar development model, but I see this as a serious flaw with it... Andrew
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 01:28:28PM -0800, Tom wrote: On Tue, Dec 02, 2003 at 08:51:50PM +0100, Andreas Rottmann wrote: Tom [EMAIL PROTECTED] writes: On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: rather far from changing anything in the kernel memory. Andreas is definitely right that the hole doesn't look like that it is that dangerous. [snip] If it wasn't a big deal we wouldn't be talking about it. It shut down servers. It's dangerous enough. Note the looks like. I read all the words but took a completely different meaning :-) I'm from the South, we have different speech patterns... South of where? the hole doesn't look like that it is that dangerous means something different than the hole doesn't look like that it is dangerous in my ears ... that is diminuitve in my dialect if you don't put emphasis on it :-) As far as security goes, we have to take 'dangerous' to mean exactly that, diminutive or not. But if it didn't look like a vulnerability then we can't blame anyone for missing it. -- --- Geoff Richards --- http://ungwe.org/ --- I tried to fling my shadow at the moon, The while my blood leapt with a wordless song. -- Theodore Roethke
Re: Backport of the integer overflow in the brk system call
On Wed, 3 Dec 2003 10:20, Andrew Pollock [EMAIL PROTECTED] wrote: What bugs the hell out of me is that people with nothing better to do with their time can sit on the lkml and watch what's getting fixed, and put more analysis into individual fixes than the kernel maintainers themselves can, and cook up an exploit for what all and sundry previously believed to be reasonably benign. I love the bazaar development model, but I see this as a serious flaw with it... Of course someone could look at the MS fixes and do some decompilation for a similar result. Sure it would be more difficult to analyse the assembler code produced from decompilation than to analyse C source, but OTOH there is no possibility for other people to try to fix bugs either. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 11:46:45PM +, Geoff Richards wrote: South of where? USA. North Carolina. Not South Carolina. Remember that. Redhat is in North Carolina. joke I always wonder if those mascara-wearing Cure-listening long-haired Linux skater punks ever get into trouble out in those Redneck bars. There's poofter places around but it's kind of hard to avoid trouble indefinitely. I learned you need to wear big shit-kicking boots and they ignore you. If you're openly superior, trouble always follows. You got klansmen, constructions, crackheads, iterant workers, and marines. SC is worse. Tennessee is worse still. And North Florida they'll leave your ass in the swamp. As far as security goes, we have to take 'dangerous' to mean exactly that, diminutive or not. But if it didn't look like a vulnerability then we can't blame anyone for missing it. Yeah, it was purely a misreading on what he said, no need to pile on *that* guy. But blame or not if a real showstopper gets out in future, it's not good!
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 11:17:19AM +1100, Russell Coker wrote: Of course someone could look at the MS fixes and do some decompilation for a similar result. Sure it would be more difficult to analyse the assembler code produced from decompilation than to analyse C source, but OTOH there is no possibility for other people to try to fix bugs either. The point being that you can't get a prerelease MS fix, so by the time MS has released it, the general population has no excuse for not applying it, so decompilation of should be more pointless (I know in reality no one applies MS fixes in a timely fashion, so there is still an shrinking window of opportunity). The only way to have avoided this kernel vulnerability from day-0 of discovery/fix release would have been to be constantly upgrading to pre-release kernels. I'm starting to sound like I'm trolling for closed-source development models or something, which is not the case, I'm just concerned by the security implications of what I've been talking about re the window of time between a believed to be harmless bug fix release in a pre-release kernel and the release of the next stable version that incorporates that fix. Andrew
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: On Wed, Dec 03, 2003 at 11:17:19AM +1100, Russell Coker wrote: The only way to have avoided this kernel vulnerability from day-0 of discovery/fix release would have been to be constantly upgrading to pre-release kernels. I'm starting to sound like I'm trolling for closed-source development models or something, which is not the case, Smartcards would have avoided the Debian compromise: merely having a compromised DD box would have prevented bad guy from getting on the box. It's all about layers of defense. I think the DD's should seriously think about requiring smartcards. It would have prevented the proxmiate cause of our recent troubles.
OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Tue, 02 Dec 2003, Tom wrote: I think the DD's should seriously think about requiring smartcards. It would have prevented the proxmiate cause of our recent troubles. Smartcards are not a magical panacea either. The problems associated with them aren't too terribly different from those associated with keys or other forms of physical security, notably, that they can be stolen, or the output from them duplicated. Refer to the ongoing saga between DirectTV and satelite pirates for a trivially applicable example. From my perspective, Smartcards do little to raise the bar. They merely move the bar sideways. Don Armstrong -- THERE IS NO GRAVITY THE WORLD SUCKS -- Vietnam War Penquin Lighter http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: The only way to have avoided this kernel vulnerability from day-0 of discovery/fix release would have been to be constantly upgrading to pre-release kernels. Yes but also the debian servers would not have been vulnerable if they had used 2.4.23. At least not at that point in time. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 05:19:22PM -0800, Tom wrote: I think the DD's should seriously think about requiring smartcards. It would have prevented the proxmiate cause of our recent troubles. No, we have to deal with a large population of untrusted individuals. Even if we can keep outsiders out of our systems (which sounds for me more and more unlikely) then we still have to face intruders from inside. You know the numbers tells you it will happen. Even if it is painful to decide: more priveledges to DDs on a need-to-have base. And: I am the last person who think it is fine to support a more powerful elite, but I dont see a way around it. You still can earn an account for a service, if you proof yourself worth. Thinking of web page translators, ftp-masters or whatever. If we are aware about that risk, and have established some midigation, we can start to address the other risks, which are harder to tackle. Smart Cards for example will require a huge investment. And sadly it is not one a sponsor can cover easyly. But using them will, for sure make the trust in a developers signature stronger. It will not allow us to trust the developer more. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 02:57:11AM +0100, Bernd Eckenfels wrote: On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: The only way to have avoided this kernel vulnerability from day-0 of discovery/fix release would have been to be constantly upgrading to pre-release kernels. Yes but also the debian servers would not have been vulnerable if they had used 2.4.23. At least not at that point in time. Um, what? Nov 19 17:00 Attacker logs into klecker with sniffed password Nov 19 17:08 Root-kit installed on klecker Nov 19 17:20 Attacker logs into master with same sniffed password Nov 19 17:47 Root-kit installed on master Nov 19 18:30 Attacker logs into murphy with service account from master Nov 19 18:35 Root-kit installed on murphy Nov 19 19:25 Oopses on murphy start Nov 20 05:38 Oopses on master start Nov 20 20:00 Discovery of Oopses on master and murphy Nov 20 20:54 Root-kit installed on gluck Nov 20 22:00 Confirmation that debian.org was compromised Nov 21 00:00 Deactivation of all accounts Nov 21 00:34 Shut down security.debian.org Nov 21 04:00 Shut down gluck (www, cvs, people, ddtp) Nov 21 08:30 Point www.debian.org to www.de.debian.org Nov 21 10:45 Public announcement Nov 21 16:47 Developer information updated Nov 21 17:10 Shut down murphy (lists) Nov 22 02:41 security.debian.org is back online Nov 25 07:40 lists.debian.org is back online Nov 28 22:39 Linux 2.4.23 released ^ -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Backport of the integer overflow in the brk system call
On Wed, 3 Dec 2003 12:19, Tom [EMAIL PROTECTED] wrote: Smartcards would have avoided the Debian compromise: merely having a compromised DD box would have prevented bad guy from getting on the box. It's all about layers of defense. I think the DD's should seriously think about requiring smartcards. It would have prevented the proxmiate cause of our recent troubles. I agree that smartcards would help a lot. However as has been previously suggested the cost of 1200+ smart-card readers is probably prohibitive. I have sent a message to Werner asking if the GPG smart-card device could be re-implemented with a USB interface. I think that a USB dongle with GPG technology would be a good option as most developer's machines already have USB support. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backport of the integer overflow in the brk system call
On Wed, 3 Dec 2003 13:02, Bernd Eckenfels [EMAIL PROTECTED] wrote: Even if it is painful to decide: more priveledges to DDs on a need-to-have base. Every DD needs to have immediate access to servers running each of the supported architectures. I use mainly i386. If I have to jump through hoops to get an account on an M68K machine then I probably won't be in a great hurry to look into bugs reported on that architecture that I can't reproduce on i386, maybe such bugs will slip so far down my priority list that they never get fixed. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 08:47:10PM -0600, Steve Langasek wrote: On Wed, Dec 03, 2003 at 02:57:11AM +0100, Bernd Eckenfels wrote: On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: The only way to have avoided this kernel vulnerability from day-0 of discovery/fix release would have been to be constantly upgrading to pre-release kernels. Yes but also the debian servers would not have been vulnerable if they had used 2.4.23. At least not at that point in time. Um, what? Nov 19 17:00 Attacker logs into klecker with sniffed password Nov 19 17:08 Root-kit installed on klecker [...] Nov 28 22:39 Linux 2.4.23 released ^ Bernd is correct, though - if the machines had been running 2.4.23, they wouldn't have been vulnerable. The fact that it was impossible to do so doesn't enter into the equation when you're working from blind assertions. g - Matt
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, 3 Dec 2003 12:34, Don Armstrong [EMAIL PROTECTED] wrote: Smartcards are not a magical panacea either. True. The problems associated with them aren't too terribly different from those associated with keys or other forms of physical security, notably, that they can be stolen, or the output from them duplicated. Using a smart-card means that logging in does not merely require something you know but also something you have. All the good security guides say that security should depend on something you know and something you have, smart-cards plus a password meets this criteria. Refer to the ongoing saga between DirectTV and satelite pirates for a trivially applicable example. That's a case of a smart-card used to decode distributed content (IE something like DECSS in principle). Encryption of one to many is a very different problem to individual encryption/authentication. The problem we are trying to solve is easier. Also in the DirectTV saga cracking the cards allegedly cost $25M. GPG smart-cards are entering the market. If GPG is crackable then we have lost regardless. If GPG is secure then GPG smart-cards will do as long as they are not stolen. Having revokation proceedures for stolen cards and DD's reliable enough to follow them should deal with this. From my perspective, Smartcards do little to raise the bar. They merely move the bar sideways. I think that they raise the bar a lot. They raise it from something that can be cracked by any script kiddie to something that requires a lot of money and expertise. That is a significant benefit. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backport of the integer overflow in the brk system call
Frederik Dannemare wrote: Hi everybody, just curious: any particular reason why we didn't see a backport any sooner of the integer overflow in the brk system call (see recent announcement by Wichert Akkerman: http://lists.debian.org/debian-security-announce/debian-security-announce-2003/msg00212.html) like we did with the ptrace issue some time back? Wasn't it (the brk vuln) considered to be threatening enough to justify a quick fix, or was it because the fix by Andrew Morton didn't say (kerne changelog) enough about the potential seriousness of the vuln, or? forgot to say: hat's off to the forensics guys. great work! I really appreciate that we now know what helped the attacker gain root. -- B/R, Frederik Dannemare
