text: Title: Port parsing can overflow (TOB-K8S-015: Overflows when using strconv.Atoi and downcasting the result)
  Body: This issue was reported in the [Kubernetes Security Audit Report](https://github.com/kubernetes/community/blob/master/wg-security-audit/findings/Kubernetes%20Final%20Report.pdf)
  
  **Description**
  The strconv.Atoi function parses an int - a machine dependent integer type, which, for 64-bit targets will be int64. There are places throughout the codebase where the result returned from strconv.Atoi is later converted to a smaller type: int16 or int32. This may overflow with a certain input. An example of the issue has been included in Figure 1.
  
  ```
  v, err := strconv.Atoi(options.DiskMBpsReadWrite)
  diskMBpsReadWrite = int32(v)
  ```
  Figure 13.1: pkg/cloudprovider/providers/azure/azure_managedDiskController.go:105
  
  Additionally, there are many code paths that parse ports, and do so differently and in a manner lacking checks for a proper port range. An example of this has been identified within kubectl when handling port values.
  
  Kubectl has the ability to expose particular Pod ports through the use of kubectl expose. This command uses the function updatePodPorts, which uses strconv.Atoi to parse a string into an integer, then downcasts it to an int32 (Figure 2).
  
  ```
  // updatePodContainers updates PodSpec.Containers.Ports with passed parameters.
  func updatePodPorts(params map[string]string, podSpec *v1.PodSpec) (err error) {
      port := -1
      hostPort := -1
      if len(params["port"]) > 0 {
          port, err = strconv.Atoi(params["port"]) // <-- this should parse port as strconv.ParseUint(params["port"], 10, 16)
          if err != nil {
              return err
          }
      }
         // (...)
      // Don't include the port if it was not specified.
      if len(params["port"]) > 0 {
          podSpec.Containers[0].Ports = []v1.ContainerPort{
              {
                  ContainerPort: int32(port), // <-- this should later just be uint16(port)
              },
          }
  ```
  Figure 13.2: Relevant snippet of the updatePodPorts function.
  
  This error has been operationalized into a crash within kubectl when overflowing provided ports. Starting with a standard deployment with no services, we can observe the expected behavior (Figure 3).
  
  ```
  root@k8s-1:~# cat nginx.yml
  apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
  kind: Deployment
  metadata:
    name: nginx-deployment
  spec:
    selector:
      matchLabels:
        app: nginx
    replicas: 1 # tells deployment to run 2 pods matching the template
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
          - containerPort: 80
          
  root@k8s-1:~# kubectl create -f nginx.yml
  deployment.apps/nginx-deployment created
  
  root@k8s-1:~# kubectl get pods
  NAME                                READY   STATUS    RESTARTS   AGE
  nginx-deployment-76bf4969df-nskjh   1/1     Running   0          2m14s
  
  root@k8s-1:~# kubectl get services
  NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
  kubernetes   ClusterIP   10.233.0.1   <none>        443/TCP   30m
  ```
  Figure 13.3: The deployment spec with service and Pod status.
  
  To trigger the overflow, we can now update the deployment through the kubectl expose command with an overflown port, overflowing from 4294967377 to 81 (Figure 4).
  ```
  root@k8s-1:/home/vagrant# kubectl expose deployment nginx-deployment --port 4294967377 --target-port 80
  service/nginx-deployment exposed
  ```
  Figure 13.4: Overflowing the port parameter.
  
  We are now able to observe this overflown port when listing the services with kubectl get services (Figure 5). We are also able to access the service on the overflown port (Figure 6).
  ```
  root@k8s-1:/home/vagrant# kubectl get services
  NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
  kubernetes         ClusterIP   10.233.0.1      <none>        443/TCP   42m
  nginx-deployment   ClusterIP   10.233.25.138   <none>        81/TCP    2s
  ```
  Figure 13.5: The overflown port got exposed.
  
  ```
  root@k8s-1:/home/vagrant# curl 10.233.25.138:81
  <!DOCTYPE html>
  <html>
  <head>
  <title>Welcome to nginx!</title>
  ...
  ```
  Figure 13.6: The result of curling the overflown service port.
  
  Furthering this issue,  we are able to also overflow the target port. After deleting the service, we can attempt to overflow the target port as well, which will result in a panic in kubectl (Figure 7 and 8).
  
  ```
  root@k8s-1:/home/vagrant# kubectl delete service nginx-deployment
  service "nginx-deployment" deleted
  root@k8s-1:/home/vagrant# kubectl get services
  NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
  kubernetes   ClusterIP   10.233.0.1   <none>        443/TCP   45m
  ```
  Figure 13.7: The deletion of the deployment.
  
  ```
  root@k8s-1:/home/vagrant# kubectl expose deployment nginx-deployment --port 4294967377 --target-port 4294967376
  E0402 09:25:31.888983    3625 intstr.go:61] value: 4294967376 overflows int32
  goroutine 1 [running]:
  runtime/debug.Stack(0xc000e54eb8, 0xc4f1e9b8, 0xa3ce32e2a3d43b34)
  	/usr/local/go/src/runtime/debug/stack.go:24 +0xa7
  k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/intstr.FromInt(0x100000050, 0xa, 0x100000050, 0x0, 0x0)
  ...
  service/nginx-deployment exposed
  ```
  Figure 13.8: The panic in kubectl when overflowing the target port.
  
  Despite the panic from kubectl (visible in Figure 8), the service is still exposed (Figure 9) and accessible (Figure 10).
  ```
  root@k8s-1:/home/vagrant# kubectl get services
  NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
  kubernetes         ClusterIP   10.233.0.1      <none>        443/TCP   46m
  nginx-deployment   ClusterIP   10.233.59.190   <none>        81/TCP    35s
  ```
  Figure 13.9: The service is exposed despite the kubectl panic and overflow.
  
  ```
  root@k8s-1:/home/vagrant# curl 10.233.59.190:81
  <!DOCTYPE html>
  <html>
  <head>
  <title>Welcome to nginx!</title>
  ...
  ```
  Figure 13.10: The service is also accessible after overflow.
  
  **Exploit Scenario**
  A value is parsed from a configuration file with Atoi, resulting in an integer. It is then downcasted to a lower precision value, resulting in a potential overflow or underflow which is not raised as an error or panic.
  
  **Recommendation**
  Short term, when parsing strings into fixed-width integer types, use strconv.ParseInt or strconv.ParseUint with appropriate bitSize argument instead of strconv.Atoi.
  
  Long term, ensure the validity of data and types. Parse and validate values with common functions. For example the ParsePort (cmd/kubeadm/app/util/endpoint.go:117) utility function parses and validates TCP port values, but it is not well used across the codebase.
  
  **Anything else we need to know?**:
  
  See #81146 for current status of all issues created from these findings.
  
  The vendor gave this issue an ID of TOB-K8S-015 and it was finding 13 of the report.
  
  The vendor considers this issue Medium Severity.
  
  To view the original finding, begin on page 42 of the [Kubernetes Security Review Report](https://github.com/kubernetes/community/blob/master/wg-security-audit/findings/Kubernetes%20Final%20Report.pdf)
  
  **Environment**:
  
  - Kubernetes version: 1.13.4