[erlang-questions] Right direction ?

Jon Watte jwatte@REDACTED
Thu Sep 29 04:01:21 CEST 2011


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? :-)

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110928/b882a7ff/attachment.htm>


More information about the erlang-questions mailing list