RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1269217 - FreeRADIUS triggers mprotect with large radius reply
Summary: FreeRADIUS triggers mprotect with large radius reply
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: freeradius
Version: 7.1
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Nikolai Kondrashov
QA Contact: Jaroslav Aster
URL:
Whiteboard:
Depends On: 1202751
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-06 16:53 UTC by dzr0001
Modified: 2021-09-09 11:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 20:36:03 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Radiusd strace output (822.28 KB, text/plain)
2016-03-09 18:32 UTC, dzr0001 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1954 0 normal SHIPPED_LIVE freeradius bug fix and enhancement update 2017-08-01 18:29:54 UTC

Description dzr0001 2015-10-06 16:53:38 UTC 
Description of problem:
A radius request causes FreeRADIUS to die when the request is too large.


Version-Release number of selected component (if applicable):


freeradius-3.0.4-6.el7



How reproducible:

100%



Steps to Reproduce:
1. Craft large radius reply
2. Request data that produces the large radius reply with radtest



Actual results:

<radtest>
# radtest $username_redacted '$password_redacted' 127.0.0.1 1812 '$key_redacted' 0 127.0.0.1
Sending Access-Request Id 164 from 0.0.0.0:44127 to 127.0.0.1:1812
        User-Name = '$username_redacted'
        User-Password = '$password_redacted'
        NAS-IP-Address = 127.0.0.1
        NAS-Port = 1812
        Message-Authenticator = 0x00
Sending Access-Request Id 164 from 0.0.0.0:44127 to 127.0.0.1:1812
        User-Name = '$username_redacted'
        User-Password = '$password_redacted'
        NAS-IP-Address = 127.0.0.1
        NAS-Port = 1812
        Message-Authenticator = 0x00
Sending Access-Request Id 164 from 0.0.0.0:44127 to 127.0.0.1:1812
        User-Name = '$username_redacted'
        User-Password = '$password_redacted'
        NAS-IP-Address = 127.0.0.1
        NAS-Port = 1812
        Message-Authenticator = 0x00
(0) No reply from server for ID 164 socket 3
</radtest>


<strace>
11577 close(15)                         = 0
11577 munmap(0x7fca6f5d7000, 4096)      = 0
11577 gettimeofday({1444148511, 7889}, NULL) = 0
11577 mprotect(0x7fca64023000, 4096, PROT_READ|PROT_WRITE) = 0
11577 open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENXIO (No such device or address)
11577 writev(2, [{"*** ", 4}, {"stack smashing detected", 23}, {" ***: ", 6}, {"/usr/sbin/radiusd", 17}, {" terminated\n", 12}], 5) = 62
11577 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fca6f5d7000
11577 futex(0x7fca6d3b8d20, FUTEX_WAKE_PRIVATE, 2147483647) = 0
11577 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
11578 +++ killed by SIGSEGV +++
11577 +++ killed by SIGSEGV +++
11576 +++ killed by SIGSEGV +++
11574 +++ killed by SIGSEGV +++
11575 +++ killed by SIGSEGV +++
11573 +++ killed by SIGSEGV +++
</strace>

<log>
# wc -l /var/log/radius/radacct/127.0.0.1/reply-detail-20151006
444 /var/log/radius/radacct/127.0.0.1/reply-detail-20151006
# ls -l /var/log/radius/radacct/127.0.0.1/reply-detail-20151006
-rw------- 1 root root 20706 Oct  6 11:21 /var/log/radius/radacct/127.0.0.1/reply-detail-20151006
# 
</log>

Expected results:

Return radius reply results. 


Additional info:

Requests for this data on FreeBSD systems will simply return a truncated RADIUS reply rather than cause the daemon to crash.
Comment 3 Nikolai Kondrashov 2016-03-08 11:35:28 UTC 
Hello DZR0001,

Thank you for the report and sorry for the delay, we're just going around to handling FreeRADIUS bugs.

Would it be possible for you to post the exact commands you've executed, or perhaps a script that produced these results? If not, could you please describe exactly what you mean by "request is too large"?

Also, did you report this upstream, if yes, could you please provide a link?

Thank you.
Comment 4 dzr0001 2016-03-08 22:49:04 UTC 
Hi,

A request that is "too large" is anything over 4096. I suspect this could be any garbage response. I've not reported this upstream.

I build a test case with garbage data if that would be helpful.
Comment 5 Nikolai Kondrashov 2016-03-09 09:25:14 UTC 
Understood. Yes, that would be most useful. Please post it if you can, please also add whatever server configuration is necessary to make it work. Thank you!
Comment 6 dzr0001 2016-03-09 18:31:48 UTC 
I installed freeradius-3.0.4-6.el7.x86_64, admittedly on a centos machine. The only configuration change that I made was to add a user in /etc/raddb/users with the following configuration:

<user>
testuser Cleartext-Password := "t3stm3!"
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
		Reply-Message += "THIS IS A LONG TEST MESSAGE 0",
		Reply-Message += "THIS IS A LONG TEST MESSAGE 1",
</user>

I increased the number of reply lines until I reached the 4096 limit. The behavior was as follows:

125 lines: works, response size was 4080
126-129 lines: errors: radclient: Received bad packet: Discarding packet: Larger than RFC limitation of 4096 bytes
130 lines: segfault with stack smashing error

I'll attach strace output from the segfaulted run.

Thanks.
Comment 7 dzr0001 2016-03-09 18:32:48 UTC 
Created attachment 1134610 [details]
Radiusd strace output
Comment 9 Nikolai Kondrashov 2016-04-29 17:12:13 UTC 
Thank you for the details, dzr0001. I found the problem in the code up to version 3.0.11. However, the latest code in the upstream v3.0.x branch has it fixed.

I'll work on backporting the fix.
Comment 15 errata-xmlrpc 2017-08-01 20:36:03 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/RHEA-2017:1954
Note You need to log in before you can comment on or make changes to this bug.