Bug 1452241 - All golang versions prior to 1.9 do not support OIDs that require more than 28 bits
Summary: All golang versions prior to 1.9 do not support OIDs that require more than 2...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: golang
Version: 7.4
Hardware: All
OS: All
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jakub Čajka
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On:
Blocks: 1452245
TreeView+ depends on / blocked
 
Reported: 2017-05-18 16:10 UTC by Mo
Modified: 2020-08-13 09:13 UTC (History)
7 users (show)

Fixed In Version: golang-1.8.3-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1452245 (view as bug list)
Environment:
Last Closed: 2017-08-01 20:21:21 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github golang go issues 19933 None closed encoding/asn1: ObjectIdentifier + crypto/x509.ParseCertificate does not support int > 28 bits 2020-04-21 22:23:10 UTC
Red Hat Bugzilla 1440605 unspecified CLOSED Openshift + ldap is not taking the pem file 2020-10-14 00:28:05 UTC
Red Hat Product Errata RHSA-2017:1859 normal SHIPPED_LIVE Moderate: golang security, bug fix, and enhancement update 2017-08-01 18:23:38 UTC

Description Mo 2017-05-18 16:10:03 UTC
Description of problem:

All golang versions prior to 1.9 do not support OIDs that require more than 28 bits.

Backport of https://github.com/golang/go/commit/94aba76639cf4d5e30975d846bb0368db8202269 is required to support the language maximum of 31 bits.

Version-Release number of selected component (if applicable):
Anything less than golang 1.9

How reproducible:

Always

Steps to Reproduce:
1. Minimum reproducer: https://play.golang.org/p/wITjVuO0-F
2. The following test cert can also reproduce the problem: https://www.viathinksoft.de/~daniel-marschall/asn.1/oid-sizecheck/oid_size_test.pem

Actual results:
asn1: structure error: base 128 integer too large

Expected results:
Correctly parse the certificate.

Additional info:

From https://github.com/golang/go/issues/19933

### What version of Go are you using (`go version`)?
`go version go1.7.5 linux/amd64` (should be the same in go 1.8+)

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mkhan/go/src/github.com/openshift/origin/Godeps/_workspace:/home/mkhan/go"
GORACE=""
GOROOT="/home/mkhan/.gvm/gos/go1.7.5"
GOTOOLDIR="/home/mkhan/.gvm/gos/go1.7.5/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build829310214=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
```

### What did you do?
Minimum reproducer: https://play.golang.org/p/wITjVuO0-F
The following test cert can also reproduce the problem: https://www.viathinksoft.de/~daniel-marschall/asn.1/oid-sizecheck/oid_size_test.pem

### What did you expect to see?
No cert parsing errors.

### What did you see instead?
`2009/11/10 23:00:00 failed to parse cert: asn1: structure error: base 128 integer too large`

The fundamental issue is that `asn1.ObjectIdentifier` is a alias for `[]int` instead of `[]big.Int`.  Based on the data http://luca.ntop.org/Teaching/Appunti/asn1.html

> INTEGER, an arbitrary integer.
>
> OBJECT IDENTIFIER, an object identifier, which is a sequence of integer components that identify an object such as an algorithm or attribute type.

and https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

> The contents octets shall be an (ordered) list of encodings of subidentifiers concatenated together. Each subidentifier is represented as a series of (one or more) octets. Bit 8 of each octet indicates whether it is the last in the series: bit 8 of the last octet is zero; bit 8 of each preceding octet is one. Bits 7 to 1 of the octets in the series  collectively encode the subidentifier. Conceptually, these groups of bits are concatenated to form an unsigned binary number whose most significant bit is bit 7 of the first octet and whose least significant bit is bit 1 of the last octet. The subidentifier shall be encoded in the fewest possible octets, that is, the leading octet of the subidentifier shall not have the value 80 (base 16).

it would seem that `[]int` is not the correct type.

However, since the type is a simple alias, it is trivial to cast between them.  Any change to the underlying type would then be considered backwards incompatible.  I will leave it to the Go team to decide if that is the case.

We have run into a real world case where an individual was assigned an OID component that requires 29 bits to represent.  Thus at this time they cannot use their certs as the current go implementation https://github.com/golang/go/blob/master/src/encoding/asn1/asn1.go#L298 is limited to 28 bits.  It should be possible to use 31+ bits from `int`.  This would be fully backwards compatible and consistent on all machines.  Using a temporary `int64`, one should be able to store greater values on machines where `int` is larger than 32 bits.  This would not be consistent across machine architectures. 
 Both of these methods are simple mitigations and would not help in cases such as https://github.com/docker/distribution/issues/1370 where http://www.oid-info.com/get/2.25 was used to store a 128 bit UUID.  They are also not tolerant of implementations that may pad the integer with unnecessary leading zeros.

Comment 12 errata-xmlrpc 2017-08-01 20:21:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:1859


Note You need to log in before you can comment on or make changes to this bug.