Bug 1595191

Summary: glibc: Backport libio vtable validation improvements
Product: Red Hat Enterprise Linux 7 Reporter: Florian Weimer <fweimer>
Component: glibcAssignee: Florian Weimer <fweimer>
Status: CLOSED ERRATA QA Contact: qe-baseos-tools-bugs
Severity: urgent Docs Contact: Vladimír Slávik <vslavik>
Priority: urgent    
Version: 7.7CC: ailan, alanm, andrew.jones, ashankar, codonell, cww, dj, dkochuka, fweimer, jiazhang, mcermak, mnewsome, pfrankli, pratshar, rvdwees, sacpatil, skolosov, sreber, vslavik
Target Milestone: rcKeywords: Patch, ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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.
Story Points: ---
Clone Of:
: 1595192 1705899 1735708 (view as bug list) Environment:
Last Closed: 2019-08-06 12:49:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1595192    
Bug Blocks: 1594286, 1643040, 1705899, 1735708    
Attachments:
Description Flags
Application compiled with GCC 2.95.3 none

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>
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>
Date:   Wed Jun 20 09:45:19 2018 +0200

    libio: Avoid ptrdiff_t overflow in IO_validate_vtable

commit c402355dfa7807b8e0adb27c009135a7e2b9f1b0
Author: Florian Weimer <fweimer>
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>
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>
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>
Date:   Wed May 16 17:00:35 2018 +0200

    support: Add TEST_COMPARE_BLOB, support_quote_blob

commit 5c0202af4b3d588c04bcec7baf05706b21cd7416
Author: Florian Weimer <fweimer>
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.