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.