[erlang-questions] Right direction ?

Joe Armstrong erlang@REDACTED
Thu Sep 29 09:19:32 CEST 2011


On Thu, Sep 29, 2011 at 4:01 AM, Jon Watte <jwatte@REDACTED> wrote:
> I've thought about adding RSA public/private key signing, but that
> ultimately goes down the route of having a CA to form a trust network, and
> since CAs tend to prove to be unworthy of trust, I'm wary.
> While it's certainly true that certificate authorities are a racket (at a
> minimum until such time as governments get in on it, for voting and
> taxation, but perhaps even after that) there is very little other choice.
> But if "nefarious type" has access to your machine, presumably he can patch
> the kernel to patch erlang to patch your beam to accept even the wrong
> checksum, so I would not worry about trying to protect against someone who
> can subvert your file system protection. Use proper permissions and proper
> account access keys for your production server for this -- you *can't*
> defend against that kind of intrusion.
> Even external verifiers are vulnerable, because if you "ask" the compromised
> machine for its "opinion" (anything from "what code is running?" to "what is
> the signature?") then, it being compromised, it can already lie and tell you
> the answers you want to hear.
> Trusted Hardware Platform, anyone? :-)

I have always assumed that the problem was trust and not security.
If I trust the source I'll accept the certificate - if the trust is
betrayed I loose.

I don't think it makes sense to ask "is the system secure?" - we
need to ask "how much effort will an attacker have to expend to break the
security". I guess protecting against script-kiddies who try to guess passwords
is one thing - but protecting against agencies who install password
sniffers in the firmware of your keyboard is a far more difficult.

The level of protection that interests me is:

     a) - protection against shooting yourself in the foot
        (ie non-malevolent mistakes) - such as rsyncing the
        wrong version of the code
      b) - protection against simple malevolent attacks (password guessing,
         exposing plain text passwords etc.)

If the system is insecure then I would hope it could resist the attack
of a "professional" cracker for several weeks - so they would give up.

Actually a) should come "out of the box" but is pretty difficult to acheive
most security violations are "obvious" after they have been exposed,
but non-evident up to then.

 /Joe


> Sincerely,
> jw
>
> --
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world. Nevertheless,
> whether we get there willingly or not, we shall soon have lower consumption
> rates, because our present rates are unsustainable.
>
>
>
> On Tue, Sep 27, 2011 at 6:25 PM, David Goehrig <dave@REDACTED> wrote:
>>
>>
>>>
>>> I don't really understand. The only (legal) way to modify the beam
>>> is to change the source and recompile. I think you have to
>>> decide exactly what the semantics of require are.
>>
>> I'm actually most concerned about the illegal way of modifying a beam:
>> a.) Sysadmin gets clever an runs rsync patching the beam with a diff from
>> one on another server (bad if that server doesn't have the right version)
>> b.) Developer gets clever and uses source control as a deployment
>> mechanism, "git push production master", overriding the version there
>> c.) Nefarious type replaces beams with other beams that have been compiled
>> with compromised security built in
>> having a loader that can check at run time (late binding)
>>
>>>
>>>   a) We check the require targets *before* compilation with
>>>        a separate program
>>
>> rebar (http://github.com/basho/rebar) already does a pretty good job at
>> this (as long as you list all your dependencies as git repos) and I've been
>> making heavy use of this over the past year.  It handles checking out and
>> compiling all the dependencies, and you can specify which specific tags you
>> depend upon.
>>>
>>>     c) we check at usage time. The first time we call daves_module and
>>> find
>>>
>>>         it has not been loaded we check the cache and so on
>>
>>
>> Right now I'm most worried about c.) in the context
>> of lib/kernel/src/code_server.erl:
>>
>> try_load_module(Mod, Dir, Caller, St) ->
>>     File = filename:append(Dir, to_path(Mod) ++
>>                            objfile_extension()),
>>     case erl_prim_loader:get_file(File) of
>>         error ->
>>             {reply,error,St};
>>         {ok,Binary,FName} ->
>>             try_load_module(absname(FName), Mod, Binary, Caller, St)
>>     end.
>>
>> Where the file pointed to by FName is now "trusted" and will then be read
>> into memory and passed off to hipe.
>> Part of the problem is I'm also introducing a new risk, because I'm
>> replacing this load bit with code that can read a URL rather than just a
>> filename, so I'd like a way to hook in to check that the file I've
>> downloaded is the same as the signature I have on file in a dets store.
>>
>>>
>>> Good stuff - needs some thought though. I was thinking of
>>> signing/validating
>>> the source with an RSA public/private keypair.
>>
>> I've thought about adding RSA public/private key signing, but that
>> ultimately goes down the route of having a CA to form a trust network, and
>> since CAs tend to prove to be unworthy of trust, I'm wary.  Self publishing
>> a RSA public key + signing a SHA hash of the source and putting both in DNS
>> seems like a reasonable way of doing it, but can also be exploited to deny
>> service by DNS cache poisoning.
>>
>> If one were to implement a pub/private key signature check, would it best
>> be done in code_server.erl or somewhere else?  That seems to be the first
>> place the files are loaded into memory at run time.
>> Dave
>>
>> --
>> -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>



More information about the erlang-questions mailing list