Hacker News Reader

Comment by lelanthran | Hacker News Reader

> I have the feeling that Haskell has one feature that could be super useful for security.

> That feature is the explicit typing of effects via monads. Just look at the recent log4j example: If effects were explicitly typed in Java, you would potentially scratch your head why you need a network monad or a "insert code into the process" effect to just log a line.

That would not have helped - the network access with RCE was a feature put into the library. What does the language selection have to do with a feature request of "We want evaluated log strings to be able to do network access with RCE"?

There's nothing special in any language (even Haskell) that will prevent this sort of thing.

View on HN

Haskell could and would absolutely prevent this problem.

Haskell does not work by aggregating together the features that a whole system needs. It works by breaking down permissions per function. You would immediately see that a function which was only ever meant to do context lookups also has network access. This would be such a crazy type for such a simple function that no one would write it this way.

Don't think about it as aggregating effects, think about it as, all of the leaves of the system have the most narrow permissions possible. And that's where most bugs are, in the leaves.

If I were writing Haskell logging functions, I would use the type "String -> IO ()" and it could do whatever it wanted including network access.

I might distinguish

    resolveFormatString     :: String -> [List Parameter] -> IO String"
    resolveFormatStringSafe :: String -> [List Parameter] -> String

but it wouldn't be "most narrow permissions possible". It would be "everything or nothing".

You would never spot this the edge of the logging API. In any case, it's easy to see this can't be the right mental model for security in Haskell. main is `IO Int` so at a gross level you can't say anything about an API or a program. Security in Haskell is about internal guarantees.

The developers of the library would immediately spot that their call does a lot more than it was ever supposed to locally. They would have a function that has a crazy permissive type like IO instead of something very narrow related to the specific functionality they need to do their one lookup.

> The developers of the library would immediately spot that their call does a lot more than it was ever supposed to locally

but the point was that if the feature is intentionally developed, then the type signatures would reflect it - it doesn't do "a lot more than it was ever supposed to".

Type systems don't tell you that a logging library shouldn't access the network. It just tells you that it does, and if this feature was intentional, then how would the type system flag it differently from a cURL-like library that writes to disk with data from the network?

And you should use the type "Log m => String -> m ()" instead of general IO.

This way, for one example, you can log in some State-derived monad, keeping logs for caller to extract and use. It is as safe as pure function. And, of course, it is trivial to implement in IO.

> You would immediately see that a function which was only ever meant to do context lookups also has network access.

I still don't see how that would help - this logging library was SUPPOSED to have network access. Would a user pause to wonder what the network access is for when it's literally part of the featurelist?

Because in Haskell, you don't give the library permissions. It doesn't matter if the library had permissions to do something. The library is not an entity.

You give functions permissions on a fine-grained basis, permissions which are automatically derived. The specific function which has the bug didn't need network access. It just needed to look something up in the environment. That function would never have a type that gave it network access, that would be insane and a type error.

> The specific function which has the bug didn't need network access.

My reading of the bug and exploit is that the specific function not only needed network access, it was a intentional feature.

> It just needed to look something up in the environment.

That's not how I understand it - it parses the user-supplied input, and fetches (and subsequently executes) the package in the user-supplied input. The environment is irrelevant.

Now, bearing in mind that this was intentionally put in, and that the feature is working as intended and expected, how would a different programming language help?

Even if written in (for example) Haskell, the behaviour will be coded the same way, because that is the intended behaviour.

Similar to warfarin. It was intended as rat poison. But then someone said “we should use this for blood thinning in humans.” And then no one questioned why doctors were prescribing rat poison because it had the feature that was desired. Saying, no language can prevent a developer from using something when they very much intentionally use it.

The point is that with a powerful Effects system, devs calling the logger would have to account for the network call in their own code. Someone might have wondered why that was needed and gotten this addressed before it was ever widespread.

> The point is that with a powerful Effects system, devs calling the logger would have to account for the network call in their own code. Someone might have wondered why that was needed and gotten this addressed before it was ever widespread.

No one would have wondered anything - it's a networked logger, with network functionality.

They might have wondered it already. And even asked, “why are we doing this? Seems like a bad idea.” But when the response is a list of reasons that may or may not be good, you just go with it. All of this was done with intention.

> What does the language selection have to do with a feature request of

Only functions with certain type signatures can do IO in Haskell. This could be broken down to be more granular such that the type system makes it clear (and even somewhat of a burden) to the caller whether writing to disk happens, or network access, or both.

Imagine the entry point to your program is given all "Effects", and then must pass them down the call stack as needed to other functions. Without the appropriate Effect, a function cannot perform the Effect. People might wonder why they were required to pass the NetworkAccess Effect into their logging calls.

Let's just hope there is a "load and execute random code from the network" effect that you could disable.

NetworkAccess Effect wouldn't be that strange for a logging system that supports multiple networked log managers like syslog.

The point isn't so much that you can disable effects. It's that you literally have no effects/capabilities unless specifically granted.

That said, I'm a bit skeptical that Haskell would have prevented this particular issue in practice. The logging monad would just likely just have been called a LoggingM (in MTL style) and most users would have been oblivious as to exactly what it was doing... and as you say: Logging to a remote system needs the network.

I guess what could have saved a Haskell program here is that there's no such thing as "download code and execute it with the same privileges as you" with being very explicit about that. (E.g. calling 'system' or whatever)

You could split it up into 2 functions I guess. A pure one that creates the log entry, then an IO one that actually saves it.

Yes, but if the IO one does <shenanigans> then you're as well off. Which is... not very.

EDIT: Just to say: I don't mean to be flippant.

Oh its fine.

And i meanr it more in that one part is literally just passing the data along, while the other part generates the data with being fed whatever is needed for it to. so, if yoj want to just log a literal string yoj wouldnt provide any additional functionality to the generator.

if you want it to expand strings, then you provide a function for that. and so on

Accesses can be distinguished too - read and write accesses are different. You can see this in [1] - there are Reader and Writer monads, where Reader is used for effectively unchangeable parameter to a monadic context (for example, socket) and Writer is used, among other things, for logging!

Well, it wouldn't prevent that one user who requested the feature. But other users would be made aware that their logging facility now does surprising new things.

Reply on news.ycombinator.com