diff -u apport-2.14.1/data/apport apport-2.14.1/data/apport
--- apport-2.14.1/data/apport
+++ apport-2.14.1/data/apport
@@ -278,10 +278,6 @@
         # Crashed process is in the same namespace as apport, not a container
         return False
 
-    if not os.path.exists('/proc/self/ns/mnt') or os.readlink('/proc/%s/ns/mnt' % pid) == os.readlink('/proc/self/ns/mnt'):
-        # Crashed process is in the same namespace as apport, not a container
-        return False
-
     return True
 
 #################################################################
@@ -310,18 +306,8 @@
     host_pid = int(sys.argv[5])
 
     if is_container_pid(host_pid):
-        error_log('pid %s crashed in a container' % sys.argv[5])
+        error_log('pid %s crashed in a container' % host_pid)
         sys.exit(0)
-    else:
-        # If it doesn't look like the crash originated from within a
-        # full container, then take the global pid and replace the local
-        # pid with it, then move on to normal handling.
-
-        # This bit is needed because some software like the chrome
-        # sandbox will use container namespaces as a security measure but are
-        # still otherwise host processes. When that's the case, we need to keep
-        # handling those crashes locally using the global pid.
-        sys.argv[1] = sys.argv[5]
 
 check_lock()
 
diff -u apport-2.14.1/debian/changelog apport-2.14.1/debian/changelog
--- apport-2.14.1/debian/changelog
+++ apport-2.14.1/debian/changelog
@@ -1,14 +1,23 @@
-apport (2.14.1-0ubuntu3.26) trusty-security; urgency=medium
+apport (2.14.1-0ubuntu3.27) trusty-security; urgency=medium
 
-  * SECURITY UPDATE: When /proc/sys/fs/suid_dumpable is enabled, do not assume
-    that a process with a file owner of the UID and GID of the user that started
-    the process is a non-tainted process. Rather check the dump mode of the core
-    file that would be created and do not write a core file if it's value is 2.
-    Thanks to Sander Bos for discovering this issue! (LP: #1726372)
+  * SECURITY UPDATE: Denial of service via resource exhaustion and
+    privilege escalation when handling crashes of tainted processes
+    (LP: #1726372)
+    - When /proc/sys/fs/suid_dumpable is set to 2, do not assume that
+      the user and group owning the /proc/<PID>/stat file is the same
+      user and group that started the process. Rather check the dump
+      mode of the crashed process and do not write a core file if its
+      value is 2. Thanks to Sander Bos for discovering this issue!
     - CVE-2017-14177
-  * SECURITY UPDATE: Change the method for determining if a crash is from a
-    container so that there are not false positives from host software using
-    pidns. Thanks to Sander Bos for discovering this issue!  (LP: #1726372)
+  * SECURITY UPDATE: Denial of service via resource exhaustion,
+    privilege escalation, and possible container escape when handling
+    crashes of processes inside PID namespaces (LP: #1726372)
+    - Change the method for determining if a crash is from a container
+      so that there are no false positives from software using PID
+      namespaces. Additionally, disable container crash forwarding by
+      ignoring crashes that occur in a PID namespace. This functionality
+      may be re-enabled in a future update. Thanks to Sander Bos for
+      discovering this issue!
     - CVE-2017-14180
 
  -- Brian Murray <brian@ubuntu.com>  Mon, 13 Nov 2017 08:54:04 -0800