Golang security and reliability

[Kevin Chadwick]

I know Go is far from plagued by these issues and I certainly wouldn't want to
trade Gos simplicity away. However, there seems to be a playing down of null
pointers and type safety issue potential.

Is this not a type safety issue?

"https://www.cvedetails.com/cve/CVE-2019-14809/"

and obviously null dereferences that can cause critical service failures to need
investigating urgently.

"https://access.redhat.com/security/cve/cve-2020-29652"

[Axel Wagner]

On Wed, Jan 20, 2021 at 12:47 PM Kevin Chadwick <m8il...@gmail.com> wrote:

I know Go is far from plagued by these issues and I certainly wouldn't want to
trade Gos simplicity away. However, there seems to be a playing down of null
pointers and type safety issue potential.

I don't understand what you are trying to say or achieve. But, to be clear:

1. Yes, Go does intentionally not attempt to build a type-system which excludes as many bugs as possible statically.

2. Yes, there is a possibility that Go software has security bugs that could (or would) have been caught by a more powerful type-system.

Language design is a trade-off and there is no such thing as a perfect type-system. Go has decided that it doesn't want to occupy the "most type-safety possible" spot in the language design space.

I don't think it is true that anyone is "downplaying" any type-safety issues of nil-pointers and the like.

Is this not a type safety issue?

"https://www.cvedetails.com/cve/CVE-2019-14809/"

I'm not entirely certain, but I don't think so. AIUI the main issue you are attributing to a type-safety problem is that (*net.URL).Port() used to return non-numeric ports on malformed URLs. But that's a library issue, not an issue with the language type-system - `int` is a supported type and it would have prevented this. A Haskell library that returns a String could have exactly the same issue, even though the Haskell type system is significantly more powerful than Go's.

This also hints at the core of *why* Go doesn't attempt to occupy the "most type-safety possible" spot in the design space. The marginal benefits of type-safety tend towards zero, while the marginal cost doesn't (I would even claim that it *increases*). At some point, you end up in a situation where your program is totally valid, including all the invariants you encoded into your types - but you still have bugs, because you encoded the wrong invariants. This is what happened here - the library said `Port` is a `string` and the type-system diligently (and correctly) checked that that's the case. And the reason the library said that isn't, that they were unable to say it's an integer.

 

and obviously null dereferences that can cause critical service failures to need
investigating urgently.

"https://access.redhat.com/security/cve/cve-2020-29652"

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ddf94844-7cf3-2366-691f-7b915e6dce1f%40gmail.com.

[Kevin Chadwick]

>> I don't understand what you are trying to say or achieve. But, to be clear:
>> 1. Yes, Go does intentionally not attempt to build a type-system which >>
excludes as many bugs as possible statically.
>> 2. Yes, there is a possibility that Go software has security bugs that could
(or would) have been caught by a more powerful type-system.

I just wanted to make a simple point and not pollute this with any agenda as I
am not going to hunt for a bug that matches any other concerns of mine or spend
any more time. I care about Go but not to the detriment of other tasks.

I will ask one thing and then I am going dark. If generics do help users avoid
type erosion then perhaps Generics should be more usable than the current plan
and smaller in scope? I don't normally like multiple ways in languages but
perhaps there should be both an easier and a more powerful Generics syntax?

This is relateable from another thread:)

>>> But, hopefully, in the-glorious-future™, this won't be needed anymore. And
>>> maybe we can get back to view interfaces as their own type

[Kevin Chadwick]

On 1/20/21 12:27 PM, Axel Wagner wrote:
>
> Language design is a trade-off and there is no such thing as a perfect
> type-system. Go has decided that it doesn't want to occupy the "most type-safety
> possible" spot in the language design space.
>
> I don't think it is true that anyone is "downplaying" any type-safety issues of
> nil-pointers and the like.

It has been stated in a thread that there have never been any type safety
related security issues. Type safety often helps avoid input validation errors,
though it can and should be done manually too.

>
> Is this not a type safety issue?
>
> "https://www.cvedetails.com/cve/CVE-2019-14809/
> <https://www.cvedetails.com/cve/CVE-2019-14809/>"
>
>
> I'm not entirely certain, but I don't think so. AIUI the main issue you are
> attributing to a type-safety problem is that (*net.URL).Port() used to return
> non-numeric ports on malformed URLs. But that's a library issue, not an issue
> with the language type-system - `int` is a supported type and it would have
> prevented this. A Haskell library that returns a String could have exactly the
> same issue, even though the Haskell type system is significantly more powerful
> than Go's.
>

Right, but had a typed function been used that took a port as an int and did
validation early. Especially with the single task principle in mind. This would
never have happened. Actually in this case either for performance or maybe
because strconv couldn't be used to produce an error. It was handled as a
function that takes a string and checks for characters 0-9.

[Axel Wagner]

On Wed, Jan 20, 2021 at 2:25 PM Kevin Chadwick <m8il...@gmail.com> wrote:

It has been stated in a thread that there have never been any type safety
related security issues.

I assume you are referring to what I said and I'd just like to point out that I never made such claims. I said two things:

I assume panics in production are sufficiently common that you could find some to point at and attribute them to a use of interfaces. Security issues are significantly less common. Maybe you can point to some? Preferably some with CVE numbers assigned.

And

 My personal projection is that security will mostly be unaffected (I don't know of many security issues in the past that were related to Go type safety or lack thereof), if it *is* affected, the effect will be positive and that type-safety will increase.

 

The first statement specifically says that you *can* likely find panics that you could attribute to interface-usage. The second statement says "I don't know of many", so it specifically *doesn't* use "none" and it also doesn't make any assertions about the actual number that exist (just the number I know of).

Right, but had a typed function been used that took a port as an int and did
validation early. Especially with the single task principle in mind. This would
never have happened.

This is true, but again, it is not related to the Go type system. The Go type system already allows you to express that invariant. In fact, "this would never have happened" is a strong indicator that the type system itself would have been sufficient for this problem. Because, apparently, if we'd actually used it to express the invariant we are interested in, it would've caught this bug. 

 

Actually in this case either for performance or maybe
because strconv couldn't be used to produce an error. It was handled as a
function that takes a string and checks for characters 0-9.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/79f1477f-70ff-bf71-b13e-e7e3d40f7857%40gmail.com.

[Kevin Chadwick]

On 1/20/21 1:46 PM, Axel Wagner wrote:
>  My personal projection is that security will mostly be unaffected (/I don't

> know of many security issues in the past that were related to Go type safety or

> lack thereof/), if it *is* affected, the effect will be positive and that
> type-safety will increase.

I apologise then. I guess I read many as any.