Bug 1595191 - glibc: Backport libio vtable validation improvements [NEEDINFO]
Summary: glibc: Backport libio vtable validation improvements
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.7
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Florian Weimer
QA Contact: qe-baseos-tools
Vladimír Slávik
URL:
Whiteboard:
Depends On: 1595192
Blocks: 1594286 1643040 1705899 1735708
TreeView+ depends on / blocked
 
Reported: 2018-06-26 10:34 UTC by Florian Weimer
Modified: 2020-01-16 07:18 UTC (History)
19 users (show)

Fixed In Version: glibc-2.17-262.el7
Doc Type: Bug Fix
Doc Text:
.Security hardening no longer causes invalid `stdio` handles in some old applications The `glibc` library uses the virtual method table (vtable) validation security hardening technique for the `libio` library. Because some old applications for the 32-bit AMD and Intel architecture supply their own vtables, the validation must be disabled for these applications. Previously, this technique was not disabled for interposed standard input and output (`stdio`) handles. As a consequence, some old applications could fail with an error message: `Fatal error: glibc detected an invalid stdio handle`. The `glibc` library now detects this situation and disables vtable validation in that case too. As a result, compatibility for running old applications is improved.
Clone Of:
: 1595192 1705899 1735708 (view as bug list)
Environment:
Last Closed: 2019-08-06 12:49:05 UTC
Target Upstream Version:
fweimer: needinfo? (sacpatil)


Attachments (Terms of Use)
Application compiled with GCC 2.95.3 (677.69 KB, application/x-executable)
2018-09-04 13:08 UTC, Andrew V. Jones
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1398413 'unspecified' 'CLOSED' 'glibc: backport libio vtable hardening' 2019-12-02 09:45:14 UTC
Red Hat Product Errata RHSA-2019:2118 None None None 2019-08-06 12:49:33 UTC
Sourceware 23236 P2 RESOLVED Harden function pointers in _IO_str_fields 2020-01-16 04:09:07 UTC
Sourceware 23313 P2 RESOLVED libio vtables validation and standard file object interposition 2020-01-16 04:09:08 UTC

Internal Links: 1398413

Description Florian Weimer 2018-06-26 10:34:49 UTC
We should backport the following upstream commits, to fix a bypass and to improve compatibility:

commit 4e8a6346cd3da2d88bbad745a1769260d36f2783
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Jun 1 10:41:03 2018 +0200

    libio: Avoid _allocate_buffer, _free_buffer function pointers [BZ #23236]

commit 2d1c89a5d7c872a1109768f50e2508cf9a4b0348
Author: Florian Weimer <fweimer@redhat.com>
Date:   Wed Jun 20 09:45:19 2018 +0200

    libio: Avoid ptrdiff_t overflow in IO_validate_vtable

commit c402355dfa7807b8e0adb27c009135a7e2b9f1b0
Author: Florian Weimer <fweimer@redhat.com>
Date:   Tue Jun 26 10:24:52 2018 +0200

    libio: Disable vtable validation in case of interposition [BZ #23313]

And backport the new test:

commit c402355dfa7807b8e0adb27c009135a7e2b9f1b0
Author: Florian Weimer <fweimer@redhat.com>
Date:   Tue Jun 26 10:24:52 2018 +0200

    libio: Disable vtable validation in case of interposition [BZ #23313]

commit 29055464a03c72762969a2e8734d0d05d4d70e58
Author: Florian Weimer <fweimer@redhat.com>
Date:   Tue Jun 26 12:20:44 2018 +0200

    libio: Add tst-vtables, tst-vtables-interposed

Comment 1 Andrew V. Jones 2018-09-04 13:08:31 UTC
Created attachment 1480775 [details]
Application compiled with GCC 2.95.3

Hello,

We have a C++ application that runs under CentOS 7.3.1611 with glibc-2.17-157, but under CentOS 7.5.1804 with glibc-2.17-222 the application "runs afoul" of the libio hardening. We are using g++ from GCC 2.95.3 to build this application.

Our test application is as follows:

```
#include <stdio.h>
#include <string>

int main(void)
{
    std::string str;
    printf("hello\n");
    return 1;
}
```

(so, we make no internal changes to the FILE* structures at all as part of this application). However, when we run this application, we obtain:

```
Fatal error: glibc detected an invalid stdio handle
Aborted
```

Our 2.95.3 build of GCC is built (unmodified) from the sources directly from the GNU website. To compile this version of GCC, we use a legacy build of GCC that we already had (that is, another version of 2.95.3). This version of 2.95.3 is able to compile applications that run under older versions of glibc (e.g., 7.3.1611), so I do not suspect the build of GCC here.

I have attached the compiled application to this issue.

Cheers,

Andrew

Comment 2 Andrew V. Jones 2018-09-04 13:11:50 UTC
My apologies, when I wrote "glibc (e.g., 7.3.1611)", I meant "glibc (e.g., glibc-2.17-157)".

Comment 3 Florian Weimer 2018-11-02 12:26:29 UTC
Further dependencies for the backport:

commit 2afece36f6006844e87d7cb2fcb1ad8b220b2623
Author: Florian Weimer <fweimer@redhat.com>
Date:   Wed May 16 17:00:35 2018 +0200

    support: Add TEST_COMPARE_BLOB, support_quote_blob

commit 5c0202af4b3d588c04bcec7baf05706b21cd7416
Author: Florian Weimer <fweimer@redhat.com>
Date:   Tue Jun 26 12:05:21 2018 +0200

    support: Add TEST_NO_SETVBUF
    
    This is sometimes needed for testing stdio streams, where the
    setvbuf call in the test driver could interfere with the test.

Comment 4 Florian Weimer 2019-01-08 17:36:59 UTC
(In reply to Andrew V. Jones from comment #1)
> Created attachment 1480775 [details]
> Application compiled with GCC 2.95.3
> 
> Hello,
> 
> We have a C++ application that runs under CentOS 7.3.1611 with
> glibc-2.17-157, but under CentOS 7.5.1804 with glibc-2.17-222 the
> application "runs afoul" of the libio hardening. We are using g++ from GCC
> 2.95.3 to build this application.

Thank you.  I have put a glibc preview build with a potential fix here:

https://people.redhat.com/~fweimer/shcBVI8M85lD/

I would appreciate if you could check if it corrects behavior with your application, too.

Comment 5 Andrew V. Jones 2019-01-09 16:54:50 UTC
Hi,

Yes, I can confirm that installing this new version of glibc corrects the old issue.

Steps:

    * Using GCC 2.95.3 on a 7.6 box

    * g++ test.cpp  # from above

    * ./a.out

    * Output: "Fatal error: glibc detected an invalid stdio handle\nAborted"

    * Created a repo.d for https://people.redhat.com/~fweimer/shcBVI8M85lD/

    * yum update

    * ./a.out

    * Output: "hello"

I also tested this with our "real" application (i.e., rather than `./a.out`) and it doesn't work on an up-to-date 7.6 box (as we knew), but it does work on a box with this new version of glibc installed.

Comment 11 Sergey Kolosov 2019-05-20 16:08:22 UTC
Verified by upstream testsuite tests: libio/tst-vtables-interposed, libio/tst-vtables. Also verified with reproducer on x86_64 https://bugzilla.redhat.com/show_bug.cgi?id=1595191#c1

Comment 19 errata-xmlrpc 2019-08-06 12:49:05 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-2019:2118

Comment 20 Florian Weimer 2019-11-22 21:59:54 UTC
Unfortunately, the fix in this bug only covers programs linked against glibc 2.1 (which was released in 1999) and later versions. Even older binaries may need the fix for bug 1775816.


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