Bug#1000031: Obsolete pcre3 library
You can build the server without PCRE, even if the PCRE libraries are on the system. Just do: ./configure --with-pcre=no and it will fall back to Posix regular expressions.
Bug#929466: FreeRADIUS opinion of this issue
Here's what we sent CVE. In short, there is no actual "exploit". --- We disagree with this CVE. In the GitHub report [1], the RedHat reporter claims: > we are aware of a way to exploit this, No description of this alleged exploit has been shared with us. Our security contact is "secur...@freeradius.org", which has been active for almost 20 years. This address and security instructions are available on our web site at: https://freeradius.org/security/ It is not clear why RedHat would refuse to share information about this issue, as is normal practice. In the GitHub report, RedHat further claims that exploitation > ... requires the attacker to already have "high privileges" (that is, he > needs to have access to the radiusd user) Which demonstrates that this issue is largely nonsense. A full explanation follows. While the FreeRADIUS server runs as user/group "radiusd/radiusd", that account has no login shell, no home directory, and no default password. The account is used solely to run the FreeRADIUS server, and to control ownership of configuration files and log files. These files are typically administered solely by the "root" user. As such, the CVE can be better stated as "if the root user misconfigures FreeRADIUS, then the RADIUS server can later elevate privileges to root". We have to ask why the "root" user would need to leverage a less-privileged account in order to gain "root" permissions. Further, anyone who can operate as the RADIUS server can perform all RADIUS authentication and authorization. i.e. authenticating all users on the network, including unknown and malicious users. There is at this time no known exploit which would let malicious users gain access to the "radiusd" user. Therefore as discussed here, there is simply no way for anyone to *gain* privileges through this alleged issue. In addition, there also appears to be disagreement within RedHat about the severity and scope of this issue. The original reporter [2] states: > The su directive to logrotate ensures that log rotation happens under the > owner of the logs. Otherwise, logrotate runs as root:root, potentially > enabling privilege escalation if a RCE is discovered against the > FreeRADIUS daemon. > > This attack avenue seems quite unlikely to me. We agree. We take great care in securing FreeRADIUS. We use multiple source code analyzers and fuzzing tests. Even the most charitable interpretation of this issue shows that the vulnerability is theoretical in nature, and is not currently exploitable. As such, we disagree with the issuance of this CVE. We also express dismay at the process by which this CVE was issued. We recommend that security "experts" follow best practices in discussing issues with authors prior to requesting spurious CVEs. [1] https://github.com/FreeRADIUS/freeradius-server/pull/2666#issuecomment-495511510 [2] https://github.com/FreeRADIUS/freeradius-server/pull/2666#issue-276755666 --- signature.asc Description: Message signed with OpenPGP
Bug#923034: FreeRADIUS status
We've been looking for a new Debian maintainer for a while. What, exactly, is in "bad shape" about this package? If there are issues, we can work towards fixing them. The software is widely used by many tens of thousands of sites. I hope it's not going to be removed from Debian. I'll note that Debian also packages "livingston-radius", which hasn't had any source changes in 20 years. There's no mailing list, no support, and it doesn't implement any of the modern RADIUS standards. Including that package does a disservice to people who install it, and then realize it's next to useless.
Bug#907518: [RFC] Disable TLSv1.0 by default, but allow enabling it
On Dec 12, 2018, at 3:48 PM, Andrej Shadura wrote: > > On 05/12/2018 09:52, Andrej Shadura wrote: >> On 05/12/2018 00:09, Jouni Malinen wrote: >> Right, so what would you recommend for me to do in the meanwhile? >> Hardcode a minimal version just for wpa-supplicant to TLSv1.0? What >> about ciphers? Anything else? > > I would really appreciate some opinion from Jouni or other people on > this list. My $0.02 is to have an "allow TLSv1.0" configuration option, but have it disabled by default. It's what we do in FreeRADIUS. It's arguably bad in minor ways to allow TLSv1.0. But preventing people from getting online is likely worse. Alan DeKok.
Bug#823112: freeradius-client is still in active development
The repository was forked by "nmav" because we had technical disagreements about the code. The "freeradius-client" code still works, and has 99% of the functionality needed by an application using RADIUS. If an application needs more functionality, I would suggest using the libfreeradius-radius library from the main server distribution. It has many more features, such as RFC 6929 "extended" attributes. Alan DeKok. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#740857: freeradius: Upgrade to 2.2.3
Package: freeradius Version: 2.1.12 Severity: important Dear Maintainer, FreeRADIUS has been removed from testing because the package is no longer being maintained. Nearly all of the reported bugs have been fixed in the upstream release. The only other ones are debian specific. FreeRADIUS is a critical package for many tens of thousands of systems. Removing it is not really an option for those people. -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-29-generic (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages freeradius depends on: ii adduser3.113ubuntu2 ii freeradius-common 3.0.0git+dfsg-1 ii libc6 2.15-0ubuntu10.5 ii libfreeradius2 none ii libgdbm3 1.8.3-10 ii libltdl7 2.4.2-1ubuntu1 ii libpam0g 1.1.3-7ubuntu2 ii libperl5.145.14.2-6ubuntu2.4 ii libpython2.7 2.7.3-0ubuntu3.4 ii libssl1.0.01.0.1-4ubuntu5.11 ii lsb-base 4.0-0ubuntu20.3 ii ssl-cert 1.0.28ubuntu0.1 Versions of packages freeradius recommends: pn freeradius-utils none Versions of packages freeradius suggests: pn freeradius-krb5none pn freeradius-ldapnone pn freeradius-mysql none pn freeradius-postgresql none -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711486: Dialup admin
I would suggest simply not building dialup-admin, instead of removing all of FreeRADIUS. Dialup-admin has already been removed from the Version 3 release, for precisely this reason. We didn't want to remove it from a stable release because that's considered antisocial. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600465: unblock: freeradius 2.1.10+dfsg-1
Josip Rodin wrote: [For Alan: I requested for FreeRADIUS 2.1.10 to replace 2.1.9 in the future Debian 6.0 release; the former came too late in our process to be accepted automatically.] OK. This, from main/events.c, looks obviously wrong, however: + home-zombie_period_start.tv_sec = home-last_packet; + home-zombie_period_start.tv_sec = USEC / 2; Presumably the second tv_sec should be tv_usec. Yes, ouch. Yeah, that sounds like it to me, too. That change came in this commit http://github.com/alandekok/freeradius-server/commit/f8bcc0fe which actually probably fixed a fatal crash (the assert call removed because Don't check home-ev due to race conditions.), so that's still probably better than one randomized zombie period start (which can get reset and/or ignored soon enough anyway) which is why nobody else noticed. Alan, is this correct? Yes. I'll commit a fix. Alan DeKok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553387: [freeradius] FTBFS with binutils-gold
Josip Rodin wrote: Alan, can you apply this? Seems trivial enough. Yup. Added for 2.1.11. Alan DeKok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599067: freeradius: Using JRadius requires a source rebuild
Josip Rodin wrote: Alan, is there any reason for mod_jradius not to be included in src/modules/stable? I'll probably pull in the new module version for 2.1.11, and mark it as stable' then. Alan DeKok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517983: Missing patch for mod_auth_radius
Josip Rodin wrote: Alan, can you remember if any feature was omitted intentionally or not? I don't think so. Which feature was omitted? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569614: radtest: cannot initialize udpfromto: Function not implemented
Josip Rodin wrote: Most programs utilize some method of detecting which is possible on runtime, so that would be preferable. Indeed the order is different - they try IPv6 if it exists, if that fails they try IPv4, and only if both don't work they error out. For example this is how telnet(8) operates: That's hard to do for RADIUS: - send packet to IPv6 address - wait 30s for timeout - try IPv4 address Ugh. It's politer to simply use the IPv4 address by default, as it matches the default in the server. The user can still force IPv6 by using -6 on the command line, or by using an IPv6 address for the server, or by using a hostname which resolves to only an IPv6 address. Alan DeKok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b7934a8.9020...@deployingradius.com
Bug#569614: radtest: cannot initialize udpfromto: Function not implemented
Josip Rodin wrote: Cc:ing Alan (upstream) for reference - there have been two analogous reports on freeradius-users about this - localhost gets resolved into an IPv6 address as well as IPv4, the stack prefers v6, and radclient barfs. This setup has been in the wild for a while now, since the previous two reports came in on 31 Jan 2009 and 4 Jul 2009, resp., and now here. What's the best thing to do? Hack radclient to use IPv4 addresses for the server if none was specified. This will break systems that are IPv6 only. You'll need to use radclient -6 ... for those systems. Or, add more hacks to look for v6 if the v4 lookup fails. I'll see if I can put something together this week. Alan DeKok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b785e4f.8070...@deployingradius.com
Bug#416266: embedding perl, libltdl and RTLD_GLOBAL
On 09-12-09 12:23 PM, Josip Rodin wrote: Alan, what do you think about the below? The *advise example is right out of libtool documentation :) It looks OK, *if* libltdl has the lt_dladvise() functions. I've noticed this local commit: http://github.com/alandekok/freeradius-server/commit /4df74f9b1497fc4c88f9159a680707041c70a23d Maybe it's about a similar issue? Nope. That commit was to fix an issue where libltdl would crash. i.e. not return failed linking to X, but *die*, and take the application down with it. Alan DeKok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#416266: embedding perl, libltdl and RTLD_GLOBAL
On 09-12-09 1:06 PM, Josip Rodin wrote: Aha. The libtool NEWS file says it first appeared in version 2.1b (2008-02-01), and the ChangeLog file says the patch has been in libtool VCS since 2007-05-08. So it's not particularly novel, but we would need to up the dependencies a bit. You could update the internal copy of libltdl in the non-bleeding-edge branch, too. Combined with those other changes I previously suggested, that could work. I've committed a fix to 2.1.8. It requires a new macro to be defined: HAVE_LT_DLADVISE_INIT. Once that's defined, it should use the new lt_dladvise() API. I haven't added a configure check, because we're pretty close to a release of 2.1.8. Likewise, I haven't upgraded the internal copy of libltdl. I'll take a look at updating the internal copy of libltdl for 2.2.0, in a month or two. Alan DeKok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559537: freeradius: segfault in rlm_passwd
Josip Rodin wrote: I'm forwarding this to the upstream author. Alan, does this sound familiar? Nope. After a quick look through the code, it might be fixed by this: http://github.com/alandekok/freeradius-server/commit/f691b0ec7d4c92919bdd4dc81e8a86b211c00832 Alan DeKok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559537: freeradius: segfault in rlm_passwd
Tollef Fog Heen wrote: yes, this works around this specific crash. However, must all modules be written in a thread-safe fashion? Yes. If so, shouldn't rlm_passwd rather be using a mutex to ensure the file pointer isn't accessed from multiple threads at the same time? Instead, it should make the file pointer local, and not put it in a global (instance) variable. If they're not required to be thread-safe, I'm wondering how the crash could happen. I'm happy to test that patch for a while, though. A better suggestion is to remove the configuration that reads the file for every packet. FreeRADIUS already supports HUP to re-load files when they change. And reading a potentially large file for 1000 packets/s is a *very* bad idea. Alan DeKok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559537: freeradius: segfault in rlm_passwd
Tollef Fog Heen wrote: Please don't do this. I am using freeradius in a (very) low-volume environment where reading a passwd file once a second (maximum) is not a problem at all. Having the tool that updates the passwd file be run as root or be allowed to SIGHUP freeradius would be much more invasive. Use the radmin tool. You can create a tool which causes the server to reread *just* the passwd module. $ radmin radmin hup passwd For those that have 1 kpps, just add caching, which I think is there already? Sure. But the server has to work for *everyone*. Having it crash occasionally for others because you don't want to HUP it is not nice. Alan DeKok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559537: freeradius: segfault in rlm_passwd
Tollef Fog Heen wrote:
It's not like those are the only options available. As an example, like
you said, make the FILE* a local variable in get_next and get_pw_nam.
For those of us who don't want the caching, let us set the hash table
size to 0, and all is good, for those who want it, let them set it to a
bigger value, they get caching, but have to reload the module when the
file is updated. Everybody is then happy.
It seems like there is still a race condition even with your fix, since
two threads might be executing the
if (ht-fp) {
statement at the same time, leading both to close the file. So your fix
has narrowed the race, but not eliminated it.
Sure. Send a patch.
Alan DeKok.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#416266: freeradius: rlm_perl has symbol lookup errors when loading additional perl modules
Enrik Berkhan wrote: Alan DeKok schrieb: b) The output of perl -MExtUtils::Embed -e ldopts / ccopts should stop telling applications that linking will work. It won't. It's lying to you. If the libperl-dev package isn't installed, perl ... ldopts should return an error. That's completely right. Maybe you should reply on Debian Bug #186778 (http://bugs.debian.org/186778). But the package maintainers don't seem to be interested in it :( An alternative explanation makes it clearer that this is strictly a debian issue. RTDL_GLOBAL is disabled on Debian for a number of good reasons. This means that an application can link to libfoo.so, and it's symbols aren't exported to other libraries. This limitation prevents a number of bugs from occurring. However, there are cases where you *want* other libraries to use those symbols, as here. Since the system has shared libraries enabled, this means that an application cannot know at compile time which libraries it needs to link to. In this case, Perl supports dynamically loading of Perl modules... which includes shared libraries. If an application links to Perl, *and* the perl scripts load modules dynamically, *then* it will load modules at run-time. Which modules are to be used is not known at compile time. So the application cannot link to every shared library it needs, because it doesn't know which library it needs. Since RTLD_GLOBAL is turned off, the application knows it needs a library, links to it, but those symbols aren't exported to other shared libraries using that one. Since shared library dependencies are broken (Data/Dumper.so doesn't depend on libperl.so), the correct libraries aren't loaded, and the application breaks. Since no static library of libperl.a is supplied by the system, the application can't link to it. If it did exist, it's symbols could be exported, because it isn't a shared library. a) enable RTLD_GLOBAL b) supply libperl.a along with the Perl headers, so perl -MExtUtils::Embed -e ldopts stops lying to the application developer that linking works c) fix the inter-library dependencies so that loading Data/Dumper.so (etc) will cause libperl.so to be loaded, too. I understand (a) is undesired. It turns out that linking to libperl.a is almost unworkable, too. FreeRADIUS uses libtool to do cross-platform linking. This means it's very difficult to control which libperl is used for linking. The appropriate solution is (c). If there's no RTDL_GLOBAL, then the ONLY way applications can link to shared libraries at run time is if the shared library dependencies are correct. If this isn't done, then Debian systems are the *only* systems where FreeRADIUS can't use libperl. All other systems have working libraries. On top of everything else, 'perl -MExtUtils::Embed -e ldopts' outputs -lperl, but there is NO libperl.so on the system. Instead, there's only libperl.so.5.8. So using Perl to link to the Perl libraries doesn't work. Alan DeKok. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416266: freeradius: rlm_perl has symbol lookup errors when loading additional perl modules
Enrik Berkhan wrote: Maybe it would work to link libperl.a (statically) with rlm_perl to workaround the problem? I haven't tried to, yet. $ locate libperl.a $ Oops. It would be possible if there *was* a libperl.a. There's no libperl.a, and the libperl.so dependencies aren't set up correctly. I'm curious how *any* application can depend on the perl libraries, like FreeRADIUS does. My conclusion is it can't. The Perl .so's are there for amusement, not for general use. Alan DeKok. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416266: freeradius: rlm_perl has symbol lookup errors when loading additional perl modules
Stephen Gran wrote: [EMAIL PROTECTED]:~$ dpkg -S libperl.a libperl-dev: /usr/lib/libperl.a $ perl -MExtUtils::Embed -e ldopts Outputs -lperl, among other things. $ perl -MExtUtils::Embed -e ccopts Prints out where the header files are installed. But, of course, you can't *use* those header files to build an application like FreeRADIUS. You can't even believe the perl ...ldopts output, because it tells you to use -lperl, which doesn't work. The solution is simple: a) libperl.a should be installed with Perl, not libperl-dev or b) The output of perl -MExtUtils::Embed -e ldopts / ccopts should stop telling applications that linking will work. It won't. It's lying to you. If the libperl-dev package isn't installed, perl ... ldopts should return an error. Every other library FreeRADIUS uses (MySQL, etc.) installs the development library with the development headers. So if the application compiles against the headers, you're pretty sure that it will link, too. In fact, in 8 years of using FreeRADIUS, the only time that *doesn't* happen is when someone installed broken headers/libraries by hand, from a tar file. Except for libperl. Alan DeKok. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
