From: David Masover Date: 2008-08-20T13:06:25+09:00 Subject: Re: Security in use of contants On Monday 18 August 2008 04:26:43 loolek wrote: > a. May be ter*rist or whatever, don' really matter. But they are only > one guy. "Them", then. I was referring to one guy. > "get the ability to "overwrite" it?" > > Secound, play that -> i am the bad guy... > > a. I was won the ruby programmer job at the plant -> I'm in! You won the Ruby programmer job at the plant. Congratulations, you can now edit the Ruby source code where that constant was defined! It really doesn't matter at this point. > b. I hacked the box of the security guy of the plant (home machine). > Why? Becouse he/she is got connection to the inner plant network > (SSH). So i am in again! (idea from Kevin) Again, you've SSH'd in to the machine... Now, what, exactly, is stopping you from simply killing that process, editing the source (maybe copying it to a temporary location), and running it again? > e. Should i continue? The rest of your examples only highlight the problem: Once you're in, you're in. What possible scenario could he insert Ruby code into a running process, without being able to also change the constant anyway? And what possible language could he not do this in? It's harder to change a constant in a running C program, but one buffer overflow and you can do it. > "let alone in my memory space." > > Hmm, how do you mean this? The ruby code will guard the memory/ > hardware/io/etc. I really don't get you? Well, I'm assuming that if he can modify a Ruby program that is executing, he is doing so by editing its memory -- which means he has access to the memory space of the program. Which means that no matter what language the program is written in, he can now change any part of it, full stop. I suppose it's possible that you're stupid enough to use eval in places you shouldn't. That's the only other way I can think of. > But anyway -> i was first hacked the unpatched Linux kernel... Should > i continue the "how"? Great -- so you can now modify ANY memory, ANYWHERE on the system. Again: NO language will protect ANY so-called "constant" from being modified here -- except maybe Verilog. Do you know why Verilog can? Because it compiles to hardware -- meaning the only possible way to change the constant would be with a soldering iron. Do you know why it's "maybe"? Because if any part of the program is software, and needs that constant, you can always change the one line that reads the constant from hardware to read a different value instead. > "WE are saying is that you are wrong about how to go about being > secure." > > I think "hypotheticaly" -> i am right. In other words, you STILL don't > see the DANGER that the week coding language cousing? That's not an argument. This has officially descended into "No it's not! Yes it is!" I don't think it's a "week coding language". You do. Unless you're willing to say _why_ you think it's weak, we aren't going to get beyond name-calling. And I'm not going to respond to any more trolling from you. > "hell of a lot worse than "overwriting a constant"" > > Oh yes, i see now -> you don't smell the dager still, becouse you > asking this silly Q. But okay, what worse could happen? No, missing the point: If he can get into a situation where it's possible for him to modify a Ruby constant, that kind of implies that he can do ANYTHING to the Ruby program, through any of the methods you mentioned above. Which means that if he wants to make it go boom, he can still do all of the following: > a. You are dead. > b. Your home city is dead too. > c. You mom is dead too. > d. The water in your area is posioned for a long time. > e. etc. What was the point of listing them? Again, these are not caused by Ruby. These are caused by the fundamental nature of how modern operating systems work. If anyone can get their code ANYWHERE NEAR your hypothetical nuclear reactor, they damned well better be trusted. If your nuclear reactor isn't hypothetical, quit now. One example: Suppose you've somehow gotten this figured out, and you have your constants.rb file, which almost no one has access to. In there, you have: COOLING_TOLERANCE = 12345 Your attacker realizes that they can't change that file, and they can't change the constant in the program. Fine, so he goes and edits cooling_rods.rb, where the constant is actually used. He replaces this line: lower_rods if temp >= COOLING_TOLERANCE With this one: raise_rods Ok, so you make cooling_rods.rb readonly. Fine, so he goes anywhere else in the program, and edits a file he's allowed to edit, and adds the following: loop { raise_rods } Again, you could sandbox it properly. You could make sure that his code never gets to touch the raise_rods function. But you're always going to miss something -- maybe he's just a designer, writing the UI. So he goes in and swaps these two buttons: START REACTION EMERGENCY SHUTDOWN So now, when someone needs to perform an emergency shutdown, they push START REACTION instead, and the reactor goes boom. The right solution is to simply not let him touch the program that controls the cooling rods. Let him read log output from that program to build his pretty graphs.