Eivind Næss [Wed, 3 Aug 2022 15:46:28 +0000 (08:46 -0700)]
Create a new API to abstract the crypto functions used by pppd.
This re-introduces the missing DES encryption functions copied from Openssl 3.0 project. Incorporates a new API for performing MD4/MD5/SHA and encryption using DES-ECB mode.
Unit tests are included for respective digest/encryption functions using this new API. With this change, you can pass configure --without-openssl to use the internally provided functions. If you do have openssl, then it will default to use these functions. This also provides a framework to allow other vendors to provide crypto.
This closes #333, partially addresses #242 (except the pkcs11 engine support). Word has it that openssl is working on support for this, and the libp11 / opensc project are inclined not to support this.
pali [Tue, 9 Aug 2022 09:20:15 +0000 (11:20 +0200)]
pppd: Workaround for generating ppp unit id on Linux (#355)
Linux kernel has nasty bug / feature. If PPPIOCNEWUNIT is called with
negative ppp unit id (which is default option when command line argument
"unit" is not specified; and tells kernel to choose some free ppp unit id)
and the lowest unused/free ppp unit id is present in some existing network
interface name prefixed by "ppp" string then this PPPIOCNEWUNIT ioctl
fails. In this case kernel is basically unable to create a new ppp
interface via PPPIOCNEWUNIT ioctl when user does not specify some unused
and non-conflicted unit id.
Linux kernel should be fixed to choose usable ppp unit id when was
requested via PPPIOCNEWUNIT parameter -1.
Until this happens, add a workaround for pppd to help choosing some random
ppp unit id when kernel returns this error.
Simple test case (run on system when there is no ppp interface):
sudo ./pppd ifname ppp1 nodefaultroute noauth nolock local nodetach pty "./pppd nodefaultroute noauth nolock local nodetach notty"
Second pppd process without this patch prints into syslog following error:
pppd 2.4.10-dev started by pali, uid 0
Couldn't create new ppp unit: File exists
Exit.
With this patch it falls back to random ppp unit id and succeeds:
pppd 2.4.10-dev started by pali, uid 0
Using interface ppp1361
Connect: ppp1361 <--> /dev/pts/14
...
This was previously done by specifying an overriding value for _ROOT_PATH. With this change, this variable is now gone.
Instead, pathnames.h will use the SYSCONFDIR and LOCALSTATEDIR to resolve these paths. These directories is already controlled by
configure.
Package maintainers should be aware though that this may change their current configuration. The convential ./configure way is to
specify:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var/run --with-plugin-dir=/usr/lib/pppd/2.4.10
If one omit the --sysconfdir option, then the default location is by ${prefix}/etc which may not be what you want.
Paul Mackerras [Fri, 5 Aug 2022 04:06:33 +0000 (14:06 +1000)]
pppd: Fix compilation on Linux when IPV6 is disabled (#360)
This rearranges the PPP_WITH_IPV6CP guards added in commit 80b8744eb42c ("Changing INET6 to PPP_WITH_IPV6CP and adding configure
option", 2021-08-06) so that we (a) always include the rtnetlink
headers, since we need them for get_ppp_stats_rtnetlink(), and (b)
don't include eui64.h unless we have IPV6 support.
Fixes: 80b8744eb42c ("Changing INET6 to PPP_WITH_IPV6CP and adding configure option") Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Paul Mackerras [Thu, 4 Aug 2022 02:23:08 +0000 (12:23 +1000)]
pppdump: Avoid out-of-range access to packet buffer
This fixes a potential vulnerability where data is written to spkt.buf
and rpkt.buf without a check on the array index. To fix this, we
check the array index (pkt->cnt) before storing the byte or
incrementing the count. This also means we no longer have a potential
signed integer overflow on the increment of pkt->cnt.
Fortunately, pppdump is not used in the normal process of setting up a
PPP connection, is not installed setuid-root, and is not invoked
automatically in any scenario that I am aware of.
Eivind Næss [Mon, 30 May 2022 05:14:08 +0000 (22:14 -0700)]
For Linux, use the Linux / Glibc based defines instead of included headers
This is to ensure compatibility with the OS you are compiling against and that
headers are maintained in upstream projects.
- Moved PPP_EAP and PPP_ECP into respective header files in lieu of not currently
existing in the linux/ppp_defs.h
- Unchained the top-level ${topsrc_dir}/include, this folder is included for
prosterity and may continue to exist on github, but in the future eliminated from
distribution
- Bogus upstream file in glibc for <net/if_ppp.h>, its content should be replaced
with a simple include to <linux/ppp-ioctl.h>. The lack of an appropriate ifreq
structure with ppp_stats or ppp_comp_stats, implementet that inline (and tested).
- Updated instances where PPP_FCS() macro would expand the fcstab, while PPP_GOODFCS
and PPP_INITFCS is provided in <linux/ppp_defs.h>, the latter is tied to a lookup
table. It's used in two places, so add the PPP_FCS macro where applicable.
Cleanup in pppd/pppd.h, eliminate unecessary headers
This removes the need to include the following heades in pppd.h
<limits.h>, this is included where needed (main.c). The number of groups already retrieved is stored in the "int ngroups" variable.
<sys/params.h>, use MAXPATHLEN where needed
<net/if.h>, such that the value of IFNAMSIZ doesn't have to be declared to include <pppd/pppd.h>
Eivind Næss [Tue, 10 Aug 2021 23:38:45 +0000 (16:38 -0700)]
Fix include paths for plugins to use the public API of pppd
This change does a few different things.
* Projects that needs #include "config.h" should use a config.h.in for the project generated by configure in the project's local directory.
* All projects will use #include <pppd/pppd.h>, and Makefile will add -I${top_srcdir} to the appropriate *_CPPFLAGS variable.
* The inclusion of <pppd/pppdconf.h> will set the presidence for all features enabled/disabled in pppd
* Plugins will now need to use PPPD_VERSION as it conflicts with VERSION from config.h generated by autotools for third party packages
Currently, only pppoe require the use of config.h to correctly set the defines for which header files and so on was detected by configure
Other projects only needed to include <pppd/pppd.h> (and maybe a few other header files), a future change will fixup <pppd/pppd.h> to include features as needed such that it's the only needed include for a plugin. This will avoid littering the code with #ifdef/#endif constructs.
BREAKING CHANGE!
pppd/pppd.h no longer provide VERSION, third party packages are required to switch to use PPPD_VERSION. This is to avoid conflict with a source package's own VERSION as set by autotools / config.h. Also, the use of PPP_VERSION conflicts with public header files from Glibc/Linux kernel.
Example:
char pppd_version[] = PPPD_VERSION;
pppd will load plugins, and also look for the symbol "pppd_version" to validate that the plugin was built for the current version of pppd.
Eivind Næss [Sat, 7 Aug 2021 21:15:01 +0000 (14:15 -0700)]
Removing patchlevel.h
The significance of this headerfile has now been reduced as pppd now provides
pppd.pc (pkgconfig) and autotools to configure the project. Other projects can
now also configure the correct path variable:
e.g. /usr/lib/x86_64-linux-gnu/pppd/2.4.10/...
To both consider the architecture and version via pkg-tool. The only consideration
would be the missing DATE directive. But I am less worried about that as the entire
release process has now been changed with the introduction of autotools.
Also fixing up pppd/pppdconf.h.in to remove quotes around the defines
Eivind Næss [Fri, 6 Aug 2021 17:06:17 +0000 (10:06 -0700)]
Changing defines for CHAPMS, MSLANMAN, MPPE to prefix with PPP_WITH_*
To avoid bleeding over to third party projects. They are all
defined and exported by pppdconf.h either way. These projects
will stil have a consistent view of how pppd was compiled.
Eivind Næss [Fri, 6 Aug 2021 16:14:02 +0000 (09:14 -0700)]
Changing INET6 to PPP_WITH_IPV6CP and adding configure option
Based on feedback on PR #296, the option ipv6-support seems inconsistent
with the existing ipxcp option. Futhermore, the #define has been renamed
to avoid bleeding into third party projects.
pppdconf.h is already distributed and will define or undefine the
PPP_WITH_IPV6CP define.
pppd: Add support for registering ppp interface via Linux rtnetlink API
pppd currently creates ppp network interface via PPPIOCNEWUNIT ioctl API.
This API creates a new ppp network interface named "ppp<unit_id>". If user
supply option "ifname" with custom network name then pppd calls SIOCSIFNAME
ioctl to rename "ppp<unit_id>" to custom name immediately after successful
PPPIOCNEWUNIT ioctl call. If custom name is already registered then
SIOCSIFNAME ioctl fails and pppd close current channel (which destroy also
network interface).
This has side effect that in the first few miliseconds interface has
different name as what user supplied.
Tools like systemd, udev or NetworkManager are trying to query
interface attributes based on interface name immediately when new
network interface is created.
But if interface is renamed immediately after creation then these tools
fails. For example when running pppd with option "ifname ppp-wan" following
error is reported by systemd / udev into dmesg log:
[ 35.718732] PPP generic driver version 2.4.2
[ 35.793914] NET: Registered protocol family 24
[ 35.889924] systemd-udevd[1852]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
[ 35.901450] ppp-wan: renamed from ppp0
[ 35.930332] systemd-udevd[1852]: link_config: could not get ethtool features for ppp0
[ 35.939473] systemd-udevd[1852]: Could not set offload features of ppp0: No such device
There is an easy way to fix this issue: Use new rtnetlink API.
Via rtnetlink API it is possible to create ppp network interface with
custom ifname atomically. Just it is not possible to specify custom ppp
unit id.
So use new rtnetlink API when user requested custom ifname without custom
ppp unit id. This will avoid system issues with interface renaming as ppp
interface is directly registered with specified final name.
This has also advantage that if requested interface name already exists
then pppd fail during registering of networking interface and not during
renaming network interface which happens after successful registration.
If user supply custom ppp unit id then it is required to use old ioctl API
as currently it is the only API which allows specifying ppp unit id.
When user does not specify custom ifname stay also with old ioctl API.
There is currently a bug in kernel which cause that when empty interface is
specified in rtnetlink message for creating ppp interface then kernel
creates ppp interface but with pseudo-random name, not derived from ppp
unit id. And therefore it is not possible to retrieve what is the name of
newly created network interface. So when user does not specify interface
name via "ifname" option (which means that want from kernel to choose some
"free" interface name) it is needed to use old ioctl API which do it
correctly for now.
eap-tls.c: In function 'ssl_msg_callback':
eap-tls.c:1284:10: error: 'SSL3_RT_HEADER' undeclared (first use in this function); did you mean 'SSL3_RT_ALERT'?
1284 | case SSL3_RT_HEADER:
| ^~~~~~~~~~~~~~
| SSL3_RT_ALERT
Paul Mackerras [Mon, 4 Jul 2022 07:37:31 +0000 (17:37 +1000)]
pppd: Add dummy noipx option
Add "noipx" as an option that does nothing to avoid breaking
installations that have "noipx" in /etc/ppp/defaults or wherever.
(The IPX-related options were removed by commit c2881a6b71a3 ("pppd:
Drop linux IPX support (#326)", 2022-01-13)).
Jaco Kroon [Tue, 17 May 2022 08:05:27 +0000 (10:05 +0200)]
pppd/auth: Pass ipparam to auth-up and auth-down scripts
ipparam is the only way a system administrator has of passing arbitrary
information from options files to scripts, and this may be useful during
auth-up in particular. (If upstream pppd had support for an auth-fail
script, it could be useful there too.)
Signed-off-by: Jaco Kroon <jaco@uls.co.za> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Need to update the esp->ea_client.ea_namelen variable. A plugin can override the
name of the user, and the variable is passed onto the eap_chap2_response generating
the wrong response length.
Richard Purdie [Thu, 13 Jan 2022 06:48:14 +0000 (06:48 +0000)]
pppd: Drop linux IPX support (#326)
The 5.15 Linux kernel has removed ipx support, along with the userspace
visible header. This support wasn't very well maintained in the kernel
for several years so drop the support from ppp as well since this won't
be usable in future.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Jaco Kroon [Thu, 13 Jan 2022 06:38:04 +0000 (08:38 +0200)]
Expand byte count statistics to 64 bits (#298)
* Add Gigawords to radius packets where applicable.
IMPORTANT NOTE: The ioctl() only supports 32-bit counters. In order t
obtain 64-bit counters, these are now pulled in from sysfs (it's assumed
to be mounted on /sys which I'm assuming is standard).
It is unknown whether sysfs will be available everywhere, as such, keep
the ioctl() method in place, but attempt to detect wrap-overs.
If the sysfs mechanism fails, fail back to the ioctl().
Given maximum data rates, the intervals between calling this needs to be
such that no more than 4GB (2^32) bytes are sent or received in any
given interval. Mostly important for radius plugin where data
accounting may be in effect.
Towards this, a timer interval on 25 seconds is set to force a ioctl()
poll irrespective of the rate of stats update calls. This may be
important for especially radius that needs to provide interim-update
intervals, if the interim updates is too long and the counters could
wrap-over twice in a single interval. At 25 seconds we should detect
all wraps up to an effective data rate of 1.37Gbps, which for my
purposes is adequate.
Possible downsides, 4 files are opened, read and closed every time
statistics is requested. This results in 12 system calls every single
time statistics is required, compared to 1 for the ioctl. Efficiency is
unknown, but as a rule of thumb fewer system calls are better, this is
however not a critical path in my opinion, so should not be a problem.
If required I can run a few benchmarks using gettimeofday() to measure
actual impact.
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
* Use netlink if possible to obtain 64-bit stats.
This uses two system calls per round.
This should be preferred where available. It seems the RTM_GETSTATS was
only added from 2016 some point (4.7.0 as per pali), which is in my
opinion old, but given experience with certain embedded systems does
need to be supported.
Pali Rohár [Tue, 21 Dec 2021 17:10:27 +0000 (18:10 +0100)]
pppoe-discovery: Remove duplicate and unused includes
Some of specified include header files in pppoe-discovery.c are duplicate
and some of them are unused. Remove all these include lines which are not
needed.
ipv6cp: Add support for ipv6cp-use-remotenumber option
This new option cause that pppd would use "remotenumber" option value for
negotiating IPv6 remote interface identifier.
It is expected that "remotenumber" option in this case is set either to MAC
address, IPv4 address, IPv6 address or telephone number (with or without
plus sign) of remote peer system.
This option is useful for PPPoE connections to generate stable and
predicable IPv6 remote interface identifier as "remotenumber" is set by
pppoe.so plugin to MAC address of remote ethernet peer.
Similarly dial-up connections set "remotenumber" to telephone number of the
remote system and VPN-based ppp plugins set "remotenumber" to address of
remote peer (in case VPN connection is based on IPv4 transport protocol
then address is set to IPv4, if based on IPv6 then remotenumber is IPv6
address).
Having stable IPv6 interface identifiers in ipv6cp is really important.
Pali Rohár [Sat, 5 Jun 2021 16:51:52 +0000 (18:51 +0200)]
ipv6cp: Add support for ipv6cp-nosend option
This new option cause that pppd would not send our local IPv6 interface
identifier to peer during IPv6 interface identifier negotiation. Like
nosendip option for IPv4.
Paul Mackerras [Fri, 10 Dec 2021 21:40:57 +0000 (08:40 +1100)]
pppoe: Print packet fields in hex if they contain non-printable characters
This adds logic to pppoe_printpkt to print text fields as hex if the
field contains any non-printable characters. This is so that a
malicious, buggy or hacked access concentrator can't cause us to send
non-printing characters to syslog.
Daniel Barlow [Sat, 20 Nov 2021 04:58:17 +0000 (04:58 +0000)]
pppd: Add ipv6-{up,down}-script options (#321)
These allow a user to specify the paths to the scripts
usually located at /etc/ppp/ipv6-up and /etc/ppp/ipv6-down,
similarly to the existing ip-up-script and ip-down-script
options
Paul Mackerras [Sat, 16 Oct 2021 03:01:46 +0000 (14:01 +1100)]
Merge pull request #297 from mjeveritt/patch-11-test-pr
pppd: Add option to ask peer for WINS address
This adds a 'usepeerwins' option, analogous to the usepeerdns option,
to ask the peer for WINS server addresses. Nothing is done with
the addresses provided other than to pass them to the ip-up
script in environment variables.
With this, if the peer sends an IPCP Configure-NAK containing
WINS addresses, we will request them in the following IPCP
Configure-Request.
Co-authored-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Michael Everitt <gentoo@veremit.xyz> Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> Signed-off-by: Michael Everitt <michael@2e0cer.net>
Eivind Næss [Thu, 24 Jun 2021 23:06:11 +0000 (16:06 -0700)]
Improve the PEAP contribution by Rustam Kovhaev
These changes adds to his contribution by
* Adding options to perform CA/CRL checking and certificate validation
consistent with what is already been done for EAP-TLS
* Certificate validation is now in line with what is already been done
for EAP-TLS. Users can now set "remotename" and "tls-verify-method" to
control these.
* Validation of certificate purpose and extended key usage is controlled
by the option "tls-verify-key-usage".
* Fixing up MPPE key generation to use the new API for handling MPPE keys
* Man page is updated where appropriate for the new options.
* Added unit-tests for the PEAP code in case of crypto or parameters would
change in the future.
* Added the peap feature to configure scripts. Users can now control the
feature by specifying --enable-peap/--disable-peap.
To acheive feature parity with the EAP-TLS change, the EAP-TLS common code was
refactored into tls.c/.h such that it could be re-used in both instances.
Using PEAP/MSCHAPv2 is now supported in PPPD with this change.
pppd: Fix usage of BOTHER ioctl API on Linux (#314)
Linux architectures have different content of struct termios2 and also
different value of BOTHER macro. So do not declare any struct termios2 nor
BOTHER macro. Current definitions in ppp were applicable only for x86.
Correct definitions for current architecture are only in <asm/termbits.h>
and <asm/ioctls.h> header files. But Linux header file <asm/termbits.h> is
in conflict with glibc header file <termios.h> and only one can be included
in one source unit. Moreover both header files contains struct termios but
with different content. So it is not possible to use glibc tc* functions
with <asm/termbits.h> definitions.
For this reason provide a new include header file "termios_linux.h" which
provides custom implementation of all glibc's termios.h functions via Linux
ioctl() interface with definitions from Linux <asm/termbits.h> header file.
Thus this "termios_linux.h" is replacement for <termios.h> with additional
support for BOTHER Linux termios API.
Same "termios_linux.h" is going to be used by U-Boot's kwboot utility for
the same reason to use arbitrary baudrate value via BOTHER ioctl API.
Hopefully one day glibc will provide some API functions for functionality
provided currently by BOTHER Linux API.
CLang detected possible invalid memory access (-Wsizeof-pointer-memaccess)
rc_find_server() resets the secret by setting *secret = 0 instead of what
was likely intended: memset the entire array. In case of error, moved the
memset operation outside of the rc_find_server() function. It's only used
in one place anyway.
projects / ppp.git / log