Opened 4 years ago

Closed 4 years ago

#4589 closed task (fixed)

glibc-2.31 (CVE-2019-19126)

Reported by: Bruce Dubbs Owned by: Bruce Dubbs
Priority: high Milestone: 9.1
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

New minor version. The changelog is extensive and can be found at https://sourceware.org/ml/libc-announce/2020/msg00001.html

Change History (3)

comment:1 by Bruce Dubbs, 4 years ago

Owner: changed from lfs-book to Bruce Dubbs
Status: newassigned

comment:2 by Douglas R. Reno, 4 years ago

Priority: normalhigh
Summary: glibc-2.31glibc-2.31 (CVE-2019-19126)

A few notable things in here:

* The obsolete function stime is no longer available to newly linked
  binaries, and its declaration has been removed from <time.h>.
  Programs that set the system time should use clock_settime instead.
* The gettimeofday function no longer reports information about a
  system-wide time zone.  This 4.2-BSD-era feature has been deprecated
  for many years, as it cannot handle the full complexity of the
  world's timezones, but hitherto we have supported it on a
  best-effort basis.  Changes required to support 64-bit time_t on
  32-bit architectures have made this no longer practical.

  As of this release, callers of gettimeofday with a non-null 'tzp'
  argument should expect to receive a 'struct timezone' whose
  tz_minuteswest and tz_dsttime fields are zero.  (For efficiency
  reasons, this does not always happen on a few Linux-based ports.
  This will be corrected in a future release.)

  All callers should supply a null pointer for the 'tzp' argument to
  gettimeofday.  For accurate information about the time zone
  associated with the current time, use the localtime function.

  gettimeofday itself is obsolescent according to POSIX.  We have no
  plans to remove access to this function, but portable programs
  should consider using clock_gettime instead.
* The settimeofday function can still be used to set a system-wide
  time zone when the operating system supports it.  This is because
  the Linux kernel reused the API, on some architectures, to describe
  a system-wide time-zone-like offset between the software clock
  maintained by the kernel, and the "RTC" clock that keeps time when
  the system is shut down.

  However, to reduce the odds of this offset being set by accident,
  settimeofday can no longer be used to set the time and the offset
  simultaneously.  If both of its two arguments are non-null, the call
  will fail (setting errno to EINVAL).

  Callers attempting to set this offset should also be prepared for
  the call to fail and set errno to ENOSYS; this already happens on
  the Hurd and on some Linux architectures.  The Linux kernel
  maintainers are discussing a more principled replacement for the
  reused API.  After a replacement becomes available, we will change
  settimeofday to fail with ENOSYS on all platforms when its 'tzp'
  argument is not a null pointer.

  settimeofday itself is obsolescent according to POSIX.  Programs
  that set the system time should use clock_settime and/or the adjtime
  family of functions instead.  We may cease to make settimeofday
  available to newly linked binaries after there is a replacement for
  Linux's time-zone-like offset API.
* System call wrappers for time system calls now use the new time64
  system calls when available. On 32-bit targets, these wrappers
  attempt to call the new system calls first and fall back to the
  older 32-bit time system calls if they are not present.  This may
  cause issues in environments that cannot handle unsupported system
  calls gracefully by returning -ENOSYS. Seccomp sandboxes are
  affected by this issue.

NOTE: This *will* break libseccomp and anything that uses a seccomp sandbox on 32-bit systems. I'll have to run jhalfs on that and check on some things with systemd after this goes in.

Security related changes:

  CVE-2019-19126: ld.so failed to ignore the LD_PREFER_MAP_32BIT_EXEC
  environment variable during program execution after a security
  transition, allowing local attackers to restrict the possible
  mapping addresses for loaded libraries and thus bypass ASLR for a
  setuid program.  Reported by Marcin Kościelnicki.

comment:3 by Bruce Dubbs, 4 years ago

Resolution: fixed
Status: assignedclosed

Fixed at revision 11738.

Note: See TracTickets for help on using tickets.