From antony at phenome.org Thu Aug 4 17:54:58 2022 From: antony at phenome.org (Antony Antony) Date: Thu, 4 Aug 2022 16:54:58 +0200 Subject: [Swan-dev] adding a test domain In-Reply-To: References: Message-ID: For last couple of years I have been using an extended version of the FreSWAN diagram and added "duo" and "float" My motivation was more clear hosts, routing FLOAT with dual uplink. https://libreswan.org/wiki/images/f/f1/Testnet-202102.png I have nsrun that support sunset,sunrise, Tokyo. I also have pacifica, (in memory of Hugh Daniel), behind sunset. And arctic behind the pole. I will update the diagram : Pacifica and arctic. Along these lines, I have another proposal. To use mixed KVM + namesapce setup. The plain nodes, including the nic, could be namespace instead of kvm. I use such setup manually. If and when we tidy up the network diagrams I propose the following too: addresspools should use a separate rage on each host. Such as east pool 192.0.8.0/24 west pool192.0.9.0/24 and special cases you can configure both. On Mon, Jul 25, 2022 at 05:02:56PM -0400, Andrew Cagney wrote: > I'd like to add a domain to the test framework. The motivation is to > allow end-to-end testing of scenarios where non IPsec domains route > their traffic through IPsec gateways. For instance: > > {ROAD,TRAIN} - NORTH = NIC - {EAST,WEST} > > where NORTH and NIC would be running libreswan, while ROAD, TRAIN, > EAST, and WEST would not. > Currently this is implemented by injecting packets into the back > interface of domains such as NORTH, which isn't quite the same thing. > > My suggestion is to make two changes: > - add a second interface to ROAD so that it can route packets through NORTH > - add a new domain TRAIN that is behind NORTH > see https://libreswan.org/wiki/Test_Suite#Proposed_Network_Diagram > > For reference: > Here's the original diagram: > https://libreswan.org/wiki/Test_Suite#Original_Network_Diagram > And here's how things are today: > https://libreswan.org/wiki/Test_Suite#Network_Diagram > _______________________________________________ > Swan-dev mailing list > Swan-dev at lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev From hugh at mimosa.com Thu Aug 11 18:38:42 2022 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Thu, 11 Aug 2022 11:38:42 -0400 (EDT) Subject: [Swan-dev] integer types biting us [long] Message-ID: <76cb98e-83c6-7af7-639a-bc6c4ad1524@mimosa.com> 1) intmax_t and uintmax_t should never be used. Those types were always bit sloppy. For example, they may be quite inefficient. They used to be safe to use in code that was trying to be generic. A function parameter of this type could handle any int type thrown at it (if the signedness was right). A macro could define a temporary that could handle any int type thrown at it (but the typeof extension was better). The *intmax_t types were almost never a good idea for the result of a function unless the receiver expected that type. A nice exception is illustrated by a max function: the value of the result is bounded by the values of its arguments. But the C Standards committee has decided that preserving old ABIs is more important than preserving the standard's promise to programmers. Some ABIs (note: not produced by the Committee) use *intmax_t. The Committee wants to allow new, wider int types. It does not want to break those ABIs, so it is breaking *intmax_t: new wider integer types can be wider than *intmax_t. This is a Bad Thing: - the only point of the *intmax_t types was to create a universal integer type. This point disappears. - this promise to the C programmer has been rescinded. - The is a silent change: no compile-time error message can be generated. - there is explicitly a promise that C changes will not break programs and equally explicitly the Committee has reserved the right to break implementation This change breaks the C Standards Committee's explicit remit. I told the Committee so but they did this anyway. breaks their explicit remit. I think that this is a scandal, but they didn't listen to me. *intmax_t no longer is promised to be able to encompass all integral types of the appropriate signedness. So *intmax_t has lost all its purpose. The Committee should have removed it from the language rather than silently breaking code that used it. The ABIs that cannot change binaries should change declarations to use the appropriate explict types. This is an easy change for ABIs. 2) Andrew mentioned https://github.com/libreswan/libreswan/issues/763 [12:37] addconn overflows uintmax_t replay-window=4294967294 to replay-window=18446744073709551614 #763 [12:46] testing/pluto/pfkeyv2-replay-window-freebsd/freebsdw.console.txt [12:48] replay-window=4294967294 # UINT32_MAX - 1 4294967294 is (uint32) -2 18446744073709551614 is (uint64_t) -1 This demonstrates more than one bug. 3) [Exploring a bit] In libipsecconf the universal integer type is uintmax_t include/ipsecconf/keywords.h: struct kw_list { struct kw_list *next; struct keyword keyword; char *string; /**/ uintmax_t number; }; But also plain "int" (i.e. signed). include/ipsecconf/confread.h: typedef int knf[KEY_NUMERIC_ROOF]; struct starter_config { struct { ksf strings; knf options; str_set strings_set; int_set options_set; } setup; /* conn %default */ struct starter_conn conn_default; char *ctlsocket; /* location of pluto control socket */ /* connections list (without %default) */ TAILQ_HEAD(, starter_conn) conns; }; There are cases of a knf member being assigned a kw_list number without bounds checking. There are cases of a knf member being assigned to an unsigned object without bounds checking. I have not done a census to count the times. How many options are actually signed? (I.e. can we eliminated signed integral types?) How many (signed or unsigned) integer options cannot be limited to INTMAX_T? (I.e. can we use an signed type as a universal option holder?) Maybe we cannot have a universal integral option holder. 4) Every time we narrow an integral value to assign it to an object with an integer type, we should check if it fits. This is a special case of overflow checking. We should always do overflow checking. This is tiresome busywork. But this is major source of bugs and in particular security bugs. Especially in C code. When I code in C, I'm constantly proving to myself that overflow cannot happen. Sometimes I slip up. Sometimes the proof is tricky and should appear in comments (tiresome busywork). We should add helper functions so that it is less annoying to add the required checks. It would be nice if the C compiler could flag suspicious narrowing at compile time. Unfortunately, that would probably be unacceptably noisy. 4) Retrofitting overflow checking is typically a lot of tricky work. But it needs doing. It can have security implications. From scan-admin at coverity.com Fri Aug 12 01:51:08 2022 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Thu, 11 Aug 2022 22:51:08 +0000 (UTC) Subject: [Swan-dev] New Defects reported by Coverity Scan for antonyantony/libreswan Message-ID: <62f587dc844d6_cbfd12b15a7aaf9a0764ea@prd-scan-dashboard-0.mail> Hi, Please find the latest report on new defect(s) introduced to antonyantony/libreswan found with Coverity Scan. 5 new defect(s) introduced to antonyantony/libreswan found with Coverity Scan. 3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 1519489: Memory - corruptions (OVERRUN) /programs/pluto/connections.c: 3833 in show_one_connection() ________________________________________________________________________________________________________ *** CID 1519489: Memory - corruptions (OVERRUN) /programs/pluto/connections.c: 3833 in show_one_connection() 3827 char instance[32]; 3828 char mtustr[8]; 3829 char sapriostr[13]; 3830 char satfcstr[13]; 3831 char nflogstr[8]; 3832 char markstr[2 * (2 * strlen("0xffffffff") + strlen("/")) + strlen(", ") ]; >>> CID 1519489: Memory - corruptions (OVERRUN) >>> Allocating insufficient memory for the terminating null of the string. 3833 char bytesbuf[strlen(" 18446744073709551616 ") + strlen(" Ki B ")]; 3834 char packetsbuf[sizeof(bytesbuf)]; 3835 3836 if (oriented(c)) { 3837 if (c->xfrmi != NULL && c->xfrmi->name != NULL) { 3838 char *n = jam_str(ifnstr, sizeof(ifnstr), ** CID 1519488: Security best practices violations (DC.WEAK_CRYPTO) /programs/pluto/rekeyfuzz.c: 32 in fuzz_margin() ________________________________________________________________________________________________________ *** CID 1519488: Security best practices violations (DC.WEAK_CRYPTO) /programs/pluto/rekeyfuzz.c: 32 in fuzz_margin() 26 * Important policy lies buried here. For example, we favour the 27 * initiator over the responder by making the initiator start 28 * rekeying sooner. 29 */ 30 31 if (initiator) { >>> CID 1519488: Security best practices violations (DC.WEAK_CRYPTO) >>> "rand" should not be used for security-related applications, because linear congruential algorithms are too easy to break. 32 marg += marg * fuzz / 100.E0 * (rand() / (RAND_MAX + 1.E0)); 33 } else { 34 marg /= 2; 35 } 36 37 return marg; ** CID 1519487: Memory - corruptions (OVERRUN) /programs/pluto/state.c: 2072 in jam_state_traffic() ________________________________________________________________________________________________________ *** CID 1519487: Memory - corruptions (OVERRUN) /programs/pluto/state.c: 2072 in jam_state_traffic() 2066 unsigned outb = (st->st_esp.present ? st->st_esp.peer_bytes : 2067 st->st_ah.present ? st->st_ah.peer_bytes : 2068 st->st_ipcomp.present ? st->st_ipcomp.peer_bytes : 0); 2069 jam(buf, ", outBytes=%u", outb); 2070 2071 if (c->sa_ipsec_max_bytes != 0) { >>> CID 1519487: Memory - corruptions (OVERRUN) >>> Allocating insufficient memory for the terminating null of the string. 2072 char bytesbuf[strlen(" 18446744073709551616 ") + strlen(" Ki B ")]; 2073 readable_humber(c->sa_ipsec_max_bytes, bytesbuf, bytesbuf + sizeof(bytesbuf), "", "B"); 2074 jam(buf, ", maxBytes=%s", bytesbuf); 2075 } 2076 } 2077 ** CID 1519486: Null pointer dereferences (FORWARD_NULL) /lib/libswan/pubkey_ecdsa.c: 83 in ECDSA_ipseckey_rdata_to_pubkey_content() ________________________________________________________________________________________________________ *** CID 1519486: Null pointer dereferences (FORWARD_NULL) /lib/libswan/pubkey_ecdsa.c: 83 in ECDSA_ipseckey_rdata_to_pubkey_content() 77 * The raw IPSECKEY_PUBKEY, which could come from the 78 * internet or a config file, can include the 79 * EC_POINT_FORM_UNCOMPRESSED prefix. 80 * 81 * Allow for and strip that off when necessary. 82 */ >>> CID 1519486: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "group". 83 if (group->nss_adds_ec_point_form_uncompressed && 84 ipseckey_pubkey.len == (*e)->bytes + 1 && 85 ipseckey_pubkey_ptr[0] == EC_POINT_FORM_UNCOMPRESSED) { 86 /* ignore prefix */ 87 raw = shunk2(ipseckey_pubkey_ptr + 1, ipseckey_pubkey.len - 1); 88 group = (*e); ** CID 1491589: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1491589: Memory - corruptions (OVERRUN) /programs/pluto/kernel_xfrm.c: 2016 in netlink_policy_expire() 2010 req.id.index = upe->pol.index; 2011 req.n.nlmsg_flags = NLM_F_REQUEST; 2012 req.n.nlmsg_type = XFRM_MSG_GETPOLICY; 2013 req.n.nlmsg_len = NLMSG_ALIGN(NLMSG_LENGTH(sizeof(req.id))); 2014 2015 int recv_errno; >>> CID 1491589: Memory - corruptions (OVERRUN) >>> Overrunning struct type nlmsghdr of 16 bytes by passing it to a function which accesses it at byte offset 79 using argument "req.n.nlmsg_len" (which evaluates to 80). 2016 if (!sendrecv_xfrm_msg(&req.n, XFRM_MSG_NEWPOLICY, &rsp, 2017 "Get policy", "?", 2018 &recv_errno, logger)) { 2019 dbg("netlink_policy_expire: policy died on us: dir=%d, index=%d", 2020 req.id.dir, req.id.index); 2021 } else if (rsp.n.nlmsg_len < NLMSG_LENGTH(sizeof(rsp.u.pol))) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yq8aBKViEpsZ9KPFMeJd7kKMDjyzu82COVFw1h1aYx-2FtFrefiPxkohPqZgI7DsTRPR5L954NuJuE0J6c4ee-2B5kY-eB-_Cir5ZFqEb-2Fpy-2FZDdTxjwNXxDWd37ZfwlkdBT1REyQ39-2FHIeKX8QxWi96mkoitjeTyxisBX8MHGQJqWKUyRpIAgu3iW8QlFURJfaM3IMHn-2BRtBgG7Lqq-2BOlkHoFBy0-2BW-2BIYv-2BL2WXXjCrtsqhRzm45CjVsgWff8Ehe6XpLighldXahP3M4Tr8U19he3nzE1kBpnqFGYdXJ5e0DElhqo1n97i6Yu9y3fQ8DxSDM0W-2BwGk-3D To manage Coverity Scan email notifications for "swan-dev at lists.libreswan.org", click https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxUzCfl-2FUi6sRJtnGH1-2FWXEIl9xkb2JliKiAkqgdujeIgWYvUCIHO1g-2Ba8I-2B0nANYHmrw9-2B13a9hJ7YOPZRdlHcEQfoMvDvjqsfrRNzFQ8lscduvXP5RLkPig71dIKudxizikG_Cir5ZFqEb-2Fpy-2FZDdTxjwNXxDWd37ZfwlkdBT1REyQ39-2FHIeKX8QxWi96mkoitjeTyxisBX8MHGQJqWKUyRpIArxLNotudWUlaTyHiy5RMCV-2FloF7JJzGIyoOemnfvS56p6LtpupAmcmPAYZ6unD2SmS7RjMOaRI-2FuOcEcKSSWdJWaqMs12A3lSEMlW4IjgC-2F7tyJSGVV1ReFv0pK-2BzTOCeeyG1DNM2QFlz0YtP1RkaU-3D