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?
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.
. read the ruby source. it's very readable and unambiguous. then once =