Version 3.0.15 and 2.2.10 have been released.
Guido Vranken found some issues with OpenVPN, so I asked him to look at FreeRADIUS. The good news is we're releasing new versions of the server. The bad news is he found things: http://freeradius.org/security/fuzzer-2017.html The various vendors have already been notified, and should have patches ready. Alan DeKok.
Alan DeKok wrote:
Guido Vranken found some issues with OpenVPN, so I asked him to look at FreeRADIUS. The good news is we're releasing new versions of the server.
Download links do not work: $ wget ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.15.tar.bz2 --2017-07-17 15:45:06-- ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.15.tar.bz2 => ‘freeradius-server-3.0.15.tar.bz2’ Resolving ftp.freeradius.org (ftp.freeradius.org)... 62.210.29.29 Connecting to ftp.freeradius.org (ftp.freeradius.org)|62.210.29.29|:21... connected. Logging in as anonymous ... Login incorrect. Ciao, Michael.
Alan DeKok wrote:
Guido Vranken found some issues with OpenVPN, so I asked him to look at FreeRADIUS. The good news is we're releasing new versions of the server. The bad news is he found things: http://freeradius.org/security/fuzzer-2017.html
Thank you for the diligence and heads up. Question: Of the bugs affecting RADIUS protocol itself, it looks like they apply to some attributes that to many of us would be considered esoteric... is an attribute filter going to kill those before the affected code gets hit, or not?
On Jul 17, 2017, at 10:19 AM, Brian Julin <BJulin@clarku.edu> wrote:
Thank you for the diligence and heads up.
That took about 2 weeks of work. :(
Question: Of the bugs affecting RADIUS protocol itself, it looks like they apply to some attributes that to many of us would be considered esoteric... is an attribute filter going to kill those before the affected code gets hit, or not?
Nope. The code gets hit before any "unlang" gets run. It's in the packet decoding routines. Alan DeKok.
Good work ! I'm sure the community is glad you spent those two weeks. :) We're upgrading to 3.0.15, and will be rolling out on production next week. Hopefully, this will also solve our issues with the cache module. If not, --enable-developer may provide more information about what's going on. Regards, Nicolas Chaigneau.
-----Message d'origine----- De : Freeradius-Users [mailto:freeradius-users-bounces+nicolas.chaigneau=capgemini.com@lists.freeradius.org] De la part de Alan DeKok Envoyé : lundi 17 juillet 2017 16:28 À : FreeRadius users mailing list Objet : Re: Version 3.0.15 and 2.2.10 have been released.
On Jul 17, 2017, at 10:19 AM, Brian Julin <BJulin@clarku.edu> wrote:
Thank you for the diligence and heads up.
That took about 2 weeks of work. :(
Question: Of the bugs affecting RADIUS protocol itself, it looks like they apply to some attributes that to many of us would be considered esoteric... is an attribute filter going to kill those before the affected code gets hit, or not?
Nope. The code gets hit before any "unlang" gets run. It's in the packet decoding routines.
Alan DeKok.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Hi Alan, On 07/17/2017 04:13 PM, Alan DeKok wrote:
Guido Vranken found some issues with OpenVPN, so I asked him to look at FreeRADIUS. The good news is we're releasing new versions of the server. The bad news is he found things:
http://freeradius.org/security/fuzzer-2017.html
The various vendors have already been notified, and should have patches ready.
Thanks a lot for your work on handling these vulnerabilities. I'm working on rebasing Fedora to 3.0.15 and noticed one thing: the contents of the tarball doesn't match the tag in Git. Have you forgotten to push a commit per chance? Thanks! Nick
On Jul 18, 2017, at 3:46 AM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
Thanks a lot for your work on handling these vulnerabilities.
I'm working on rebasing Fedora to 3.0.15 and noticed one thing: the contents of the tarball doesn't match the tag in Git. Have you forgotten to push a commit per chance?
It matches for me. It's the same commit locally as on github. The problem is likely that "git tar" produces different results on different platforms. Alan DeKok.
On 07/18/2017 02:26 PM, Alan DeKok wrote:
On Jul 18, 2017, at 3:46 AM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
Thanks a lot for your work on handling these vulnerabilities.
I'm working on rebasing Fedora to 3.0.15 and noticed one thing: the contents of the tarball doesn't match the tag in Git. Have you forgotten to push a commit per chance?
It matches for me. It's the same commit locally as on github.
The problem is likely that "git tar" produces different results on different platforms.
Hmm, I was comparing the contents of archives, not archives themselves. I retried that from scratch and got the same results, below: ---:<--- nkondras@bard:~$ cd tmp/ nkondras@bard:~/tmp$ mkdir freeradius-cmp nkondras@bard:~/tmp$ cd freeradius-cmp/ nkondras@bard:~/tmp/freeradius-cmp$ git clone -q git@github.com:FreeRADIUS/freeradius-server.git nkondras@bard:~/tmp/freeradius-cmp$ cd freeradius-server/ nkondras@bard:~/tmp/freeradius-cmp/freeradius-server$ git archive --prefix=freeradius-server-3.0.15-git/ -o ../freeradius-server-3.0.15-git.tar.gz release_3_0_15 nkondras@bard:~/tmp/freeradius-cmp/freeradius-server$ cd .. nkondras@bard:~/tmp/freeradius-cmp$ wget -q ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.15.tar.bz2 nkondras@bard:~/tmp/freeradius-cmp$ tar xf freeradius-server-3.0.15.tar.bz2 nkondras@bard:~/tmp/freeradius-cmp$ tar xf freeradius-server-3.0.15-git.tar.gz nkondras@bard:~/tmp/freeradius-cmp$ diff -rqu freeradius-server-3.0.15-git freeradius-server-3.0.15 Files freeradius-server-3.0.15-git/doc/ChangeLog and freeradius-server-3.0.15/doc/ChangeLog differ Files freeradius-server-3.0.15-git/src/modules/rlm_python/rlm_python.c and freeradius-server-3.0.15/src/modules/rlm_python/rlm_python.c differ Files freeradius-server-3.0.15-git/src/modules/rlm_sql/drivers/rlm_sql_sqlite/rlm_sql_sqlite.c and freeradius-server-3.0.15/src/modules/rlm_sql/drivers/rlm_sql_sqlite/rlm_sql_sqlite.c differ nkondras@bard:~/tmp/freeradius-cmp$ nkondras@bard:~/tmp/freeradius-cmp$ nkondras@bard:~/tmp/freeradius-cmp$ diff -ru freeradius-server-3.0.15-git freeradius-server-3.0.15 diff -ru freeradius-server-3.0.15-git/doc/ChangeLog freeradius-server-3.0.15/doc/ChangeLog --- freeradius-server-3.0.15-git/doc/ChangeLog 2017-07-17 15:52:16.000000000 +0300 +++ freeradius-server-3.0.15/doc/ChangeLog 2017-07-17 15:43:00.000000000 +0300 @@ -26,10 +26,6 @@ FR-GV-305 * use strncmp() instead of memcmp() for bounded data FR-AD-001 - * Bind the lifetime of program name and python path to the module - FR-AD-002 - * Pass correct statement length into sqlite3_prepare[_v2] - FR-AD-003 * print messages when we see deprecated configuration items * show reasons why we couldn't parse a certificate diff -ru freeradius-server-3.0.15-git/src/modules/rlm_python/rlm_python.c freeradius-server-3.0.15/src/modules/rlm_python/rlm_python.c --- freeradius-server-3.0.15-git/src/modules/rlm_python/rlm_python.c 2017-07-17 15:52:16.000000000 +0300 +++ freeradius-server-3.0.15/src/modules/rlm_python/rlm_python.c 2017-07-17 15:43:00.000000000 +0300 @@ -15,7 +15,7 @@ */ /** - * $Id: 8261cfd7a34b0a7d59bba8ec7de3f3a5b42e6688 $ + * $Id: c52cec52c76a4036e4739b2bb33252c9d425ce88 $ * @file rlm_python.c * @brief Translates requests between the server an a python interpreter. * @@ -25,7 +25,7 @@ * @copyright 2002 Miguel A.L. Paraz <mparaz@mparaz.com> * @copyright 2002 Imperium Technology, Inc. */ -RCSID("$Id: 8261cfd7a34b0a7d59bba8ec7de3f3a5b42e6688 $") +RCSID("$Id: c52cec52c76a4036e4739b2bb33252c9d425ce88 $") #define LOG_PREFIX "rlm_python - " @@ -67,11 +67,6 @@ char const *name; //!< Name of the module instance PyThreadState *sub_interpreter; //!< The main interpreter/thread used for this instance. char const *python_path; //!< Path to search for python files in. - -#if PY_VERSION_HEX > 0x03050000 - wchar_t *wide_name; //!< Special wide char encoding of radiusd name. - wchar_t *wide_path; //!< Special wide char encoding of radiusd path. -#endif PyObject *module; //!< Local, interpreter specific module, containing //!< FreeRADIUS functions. bool cext_compat; //!< Whether or not to create sub-interpreters per module @@ -860,15 +855,19 @@ #if PY_VERSION_HEX > 0x03050000 { - inst->wide_name = Py_DecodeLocale(main_config.name, strlen(main_config.name)); + wchar_t *name; + + wide_name = Py_DecodeLocale(main_config.name, strlen(main_config.name)); Py_SetProgramName(name); /* The value of argv[0] as a wide char string */ + PyMem_RawFree(name); } #else { char *name; - memcpy(&name, &main_config.name, sizeof(name)); + name = talloc_strdup(NULL, main_config.name); Py_SetProgramName(name); /* The value of argv[0] as a wide char string */ + talloc_free(name); } #endif @@ -904,23 +903,23 @@ /* * Set the python search path - * - * The path buffer does not appear to be dup'd - * so its lifetime should really be bound to - * the lifetime of the module. */ if (inst->python_path) { #if PY_VERSION_HEX > 0x03050000 { - inst->wide_path = Py_DecodeLocale(inst->python_path, strlen(inst->python_path)); + wchar_t *name; + + path = Py_DecodeLocale(inst->python_path, strlen(inst->python_path)); PySys_SetPath(path); + PyMem_RawFree(path); } #else { char *path; - memcpy(&path, inst->python_path, sizeof(path)); + path = talloc_strdup(NULL, inst->python_path); PySys_SetPath(path); + talloc_free(path); } #endif } @@ -1088,14 +1087,8 @@ PyThreadState_Swap(main_interpreter); /* Swap to the main thread */ Py_Finalize(); dlclose(python_dlhandle); - -#if PY_VERSION_HEX > 0x03050000 - if (inst->wide_name) PyMem_RawFree(inst->wide_name); - if (inst->wide_path) PyMem_RawFree(inst->wide_path); -#endif } - return ret; } diff -ru freeradius-server-3.0.15-git/src/modules/rlm_sql/drivers/rlm_sql_sqlite/rlm_sql_sqlite.c freeradius-server-3.0.15/src/modules/rlm_sql/drivers/rlm_sql_sqlite/rlm_sql_sqlite.c --- freeradius-server-3.0.15-git/src/modules/rlm_sql/drivers/rlm_sql_sqlite/rlm_sql_sqlite.c 2017-07-17 15:52:16.000000000 +0300 +++ freeradius-server-3.0.15/src/modules/rlm_sql/drivers/rlm_sql_sqlite/rlm_sql_sqlite.c 2017-07-17 15:43:00.000000000 +0300 @@ -15,14 +15,14 @@ */ /** - * $Id: 9cf1aff604053f2e70ad4c6a930f16e409e8bd71 $ + * $Id: c94831da322fefbcfaa20bbe9b0ea345ab616026 $ * @file rlm_sql_sqlite.c * @brief SQLite driver. * * @copyright 2013 Network RADIUS SARL <info@networkradius.com> * @copyright 2007 Apple Inc. */ -RCSID("$Id: 9cf1aff604053f2e70ad4c6a930f16e409e8bd71 $") +RCSID("$Id: c94831da322fefbcfaa20bbe9b0ea345ab616026 $") #include <freeradius-devel/radiusd.h> #include <freeradius-devel/rad_assert.h> @@ -233,7 +233,7 @@ ssize_t len; int statement_cnt = 0; char *buffer; - char *p, *q; + char *p, *q, *s; int cl; FILE *f; struct stat finfo; @@ -321,18 +321,20 @@ /* * Statement delimiter is ;\n */ - p = buffer; + s = p = buffer; while ((q = strchr(p, ';'))) { - if ((q[1] != '\n') && (q[1] != '\0')) { + if (q[1] != '\n') { p = q + 1; statement_cnt++; continue; } + *q = '\0'; + #ifdef HAVE_SQLITE3_PREPARE_V2 - status = sqlite3_prepare_v2(db, p, q - p, &statement, &z_tail); + status = sqlite3_prepare_v2(db, s, len, &statement, &z_tail); #else - status = sqlite3_prepare(db, p, q - p, &statement, &z_tail); + status = sqlite3_prepare(db, s, len, &statement, &z_tail); #endif if (sql_check_error(db, status) != RLM_SQL_OK) { @@ -357,7 +359,7 @@ } statement_cnt++; - p = q + 1; + p = s = q + 1; } talloc_free(buffer); nkondras@bard:~/tmp/freeradius-cmp$ --->:--- Nick
On Jul 18, 2017, at 8:59 AM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
Hmm, I was comparing the contents of archives, not archives themselves. I retried that from scratch and got the same results, below:
Weird... I don't know how that happened. I'll take a look. In the end, those issues aren't exploitable and don't cause problems in normal configurations. I think it's fine to leave 3.0.15 as-is. Alan DeKok.
On 07/18/2017 04:06 PM, Alan DeKok wrote:
On Jul 18, 2017, at 8:59 AM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
Hmm, I was comparing the contents of archives, not archives themselves. I retried that from scratch and got the same results, below:
Weird... I don't know how that happened. I'll take a look.
In the end, those issues aren't exploitable and don't cause problems in normal configurations. I think it's fine to leave 3.0.15 as-is.
It's the tarball that has more commits than the Git repo, so perhaps you can just push them and update the tag? It will make it easier for me to track the packaging patches in my own repo. Thanks :) Nick
On Jul 18, 2017, at 9:12 AM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
It's the tarball that has more commits than the Git repo, so perhaps you can just push them and update the tag? It will make it easier for me to track the packaging patches in my own repo.
The issue is that the repo has more commits than the tarball. You can just grab the extra commits from github. Alan DeKok.
On 07/18/2017 04:22 PM, Alan DeKok wrote:
On Jul 18, 2017, at 9:12 AM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
It's the tarball that has more commits than the Git repo, so perhaps you can just push them and update the tag? It will make it easier for me to track the packaging patches in my own repo.
The issue is that the repo has more commits than the tarball. You can just grab the extra commits from github.
Right, got confused. Will figure something out with my repo. Thanks! Nick
Hi Alan, many many thanks for your hard work. Have a nice day, regards, Petr Linke ---------- At 17.7.2017 Alan DeKok wrote ---------- From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Date: 17. 7. 2017 15:18:10 Subject: Version 3.0.15 and 2.2.10 have been released. " Guido Vranken found some issues with OpenVPN, so I asked him to look at FreeRADIUS. The good news is we're releasing new versions of the server. The bad news is he found things: http://freeradius.org/security/fuzzer-2017.html The various vendors have already been notified, and should have patches ready. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users. html"
On 07/17/2017 03:13 PM, Alan DeKok wrote:
Guido Vranken found some issues with OpenVPN, so I asked him to look at FreeRADIUS. The good news is we're releasing new versions of the server. The bad news is he found things:
To help with fuzzing, maybe this service by Google could be helpful, https://github.com/google/oss-fuzz - Adam
On Jul 18, 2017, at 9:44 AM, Adam Majer <amajer@suse.de> wrote:
To help with fuzzing, maybe this service by Google could be helpful,
It's probably worth trying. Alan DeKok.
participants (7)
-
Adam Majer -
Alan DeKok -
Brian Julin -
Chaigneau, Nicolas -
Michael Ströder -
Nikolai Kondrashov -
petr.linke＠seznam.cz