gnrc_tftp: initialize unititialized 'tftp_context_t' #11773

miri64 · 2019-07-01T21:02:34Z

Contribution description

Testing procedure

Follow procedure in #11772. It should succeed and also not run into a failed assertion. Also try the instruction in example/gnrc_tftp's README.

Issues/PRs references

Addresses #11772.

miri64 · 2019-07-01T21:06:38Z

sys/net/gnrc/application_layer/tftp/gnrc_tftp.c

@@ -606,6 +608,7 @@ tftp_state _tftp_state_processes(tftp_context_t *ctxt, msg_t *m)
    tmp = gnrc_pktsnip_search_type(pkt, GNRC_NETTYPE_IPV6);
    ipv6_hdr_t *ip = (ipv6_hdr_t *)tmp->data;
    uint8_t *data = (uint8_t *)pkt->data;
+    ctxt->dst_port = byteorder_ntohs(udp->src_port);


I'm not 100% sure about this one. There are also other sets of this variable below... However, I observed gnrc_udp_hdr_build() getting dst_port 0 with the fix above.

I pushed a fixup that I think is more correct.

MrKevinWeiss

For the testing procedure I needed to run the following echo AAMAAGZvb2Jhcg== | base64 -d | nc -6 -u 'fe80::680d:c6ff:fed2:1f3a%tapbr0' 69
I was able to fail it on master and this PR does fix it.

It looks good generally. Please squash.

miri64 · 2019-07-03T08:44:23Z

sys/net/gnrc/application_layer/tftp/gnrc_tftp.c

-    ctxt.enable_options = use_options;
+    tftp_context_t ctxt = {
+        .dst_port = GNRC_TFTP_DEFAULT_DST_PORT,
+        .src_port = GNRC_TFTP_DEFAULT_DST_PORT,


I'm not sure this should be SRC_PORT... I'd like to do some personal testing for the "normal" operation first.

Please let me how to confirm then in the test procedure (or ping someone more knowledgeable).

Since the contributor that provided this is not active anymore, I'd say follow the README. Maybe also @bergzand has some input.

Assuming my understanding of the protocol and the implementation here is sufficient, this .src_port is the UDP port used as source by RIOT and used as destination by the peer. Both should be ephermal ports specific for this connection.

Does it make sense to default it to something invalid/unconfigured? (Do we have something like that in gnrc?)

Assuming my understanding of the protocol and the implementation here is sufficient, this .src_port is the UDP port used as source by RIOT and used as destination by the peer. Both should be ephermal ports specific for this connection.

We are in server context here, so src_port should at least be GNRC_TFTP_DEFAULT_DST_PORT (which is the default TFTP port). Ephemeral ports in GNRC are part of the gnrc_sock implementation, which this implementation does not use :-/

Does it make sense to default it to something invalid/unconfigured? (Do we have something like that in gnrc?)

If I leave it unconfigured, the testing procedure in #11772 runs into an assertion here

RIOT/sys/net/gnrc/transport_layer/udp/gnrc_udp.c

Lines 283 to 286 in a01e70a

gnrc_pktsnip_t *gnrc_udp_hdr_build(gnrc_pktsnip_t *payload, uint16_t src,

uint16_t dst)

{

assert((src > 0) && (dst > 0));

from the call here

RIOT/sys/net/gnrc/application_layer/tftp/gnrc_tftp.c

Lines 967 to 969 in a01e70a

src_port.u16 = ctxt->src_port;

dst_port.u16 = ctxt->dst_port;

udp = gnrc_udp_hdr_build(buf, src_port.u16, dst_port.u16);

This is the only application protocol purely based on GNRC (and as soon as we have async sock, I prefer to have it ported to sock_udp, but first we need to fix the bug ;-)).

If I leave it unconfigured, the testing procedure in #11772 runs into an assertion here […]

You did leave it (dst_port) unconfigered in the merged version of your PR, right? Because doesn't this allow someone to crash a RIOT node running gnrc_tftp compiled with DEVELHELP = 1 by sending a crafted input?

Arghs, this must have gotten lost, when I squashed :(

Wait no, right. I moved the initialization to 2fce095, as _tftp_state_processes relied on certain configurations of ctxt->dst_port I was unsure about. I tested it with your crafted input, and it did not crash (the server was not responding anymore, because a legal input changed its port...., see #11778).

I tested it with your crafted input, and it did not crash

My previous test input gets rejected due to the blocknum contained in it. If you compile with ENABLE_DEBUG you get (among other things):

tftp: not the packet we were waiting for, expected 1, received 0

If you change the blocknum in the test input gnrc_tftp crashes:

echo AAMAAWZvb2Jhcg | base64 -d | nc -u '[ip-address%tap0]' 69

Can you reproduces this or am I simply doing something wrong?

Yepp... Why did I touch this module -.- It's good that I deprecated it.

miri64 · 2019-07-03T10:41:16Z

I just noticed, that the server does not response ever since the shift to gnrc_netif (same old problem: link-local address without a given interface). I'll try and see if I can at least fix it for the server (the client would require an API change).

miri64 · 2019-07-03T10:52:20Z

I can at least be sure with the latest squash, that the assertion I ran into is avoided.

miri64 · 2019-07-03T12:11:38Z

Ok. I added a fix for the link-local address problem I mentioned before, but now I see, that with the fix I can still cause the server to switch source port when I send @nmeum's test message :-/....

miri64 · 2019-07-03T12:16:22Z

Ok. It is not the test message causing the port to switch, but the normal message. I'm for merging these fixes soonish and then deprecating the module, as it is obviously flawed and unused.

MrKevinWeiss

I retested. The fix still works. The docs make sense to me. Since this module will be deprecated soon anyways I think it will it would be good to have the fix in.

ACK.

miri64 added 2 commits July 1, 2019 22:55

gnrc_tftp: initialize unititialized 'tftp_context_t' values to 0

5ec0b16

gnrc_tftp: set source port for server

3d9c7ee

miri64 added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Jul 1, 2019

miri64 added this to the Release 2019.07 milestone Jul 1, 2019

miri64 requested review from kaspar030, bergzand and MrKevinWeiss July 1, 2019 21:02

miri64 mentioned this pull request Jul 1, 2019

gnrc_tftp: use of uninitialized values #11772

Closed

miri64 changed the title ~~Gnrc tftp/fix/uninitialized values~~ gnrc_tftp: initialize unititialized 'tftp_context_t' Jul 1, 2019

miri64 commented Jul 1, 2019

View reviewed changes

MrKevinWeiss reviewed Jul 3, 2019

View reviewed changes

miri64 commented Jul 3, 2019

View reviewed changes

gnrc_tftp: set dst_port when duplicated data received

2fce095

miri64 force-pushed the gnrc_tftp/fix/uninitialized-values branch from b79aa36 to 2fce095 Compare July 3, 2019 10:51

gnrc_tftp: make it working again with link-local addresses

7ba928f

MrKevinWeiss approved these changes Jul 3, 2019

View reviewed changes

miri64 mentioned this pull request Jul 3, 2019

gnrc_tftp: add deprecation note #11778

Merged

miri64 merged commit e8650f5 into RIOT-OS:master Jul 3, 2019

miri64 deleted the gnrc_tftp/fix/uninitialized-values branch July 3, 2019 12:52

miri64 mentioned this pull request Jul 3, 2019

gnrc_tftp: set port on server init #11786

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gnrc_tftp: initialize unititialized 'tftp_context_t' #11773

gnrc_tftp: initialize unititialized 'tftp_context_t' #11773

miri64 commented Jul 1, 2019

miri64 Jul 1, 2019

miri64 Jul 1, 2019

MrKevinWeiss left a comment

miri64 Jul 3, 2019

MrKevinWeiss Jul 3, 2019

miri64 Jul 3, 2019

bergzand Jul 3, 2019

miri64 Jul 3, 2019

nmeum Jul 3, 2019 •

edited

miri64 Jul 3, 2019

miri64 Jul 3, 2019

nmeum Jul 3, 2019 •

edited

miri64 Jul 3, 2019

miri64 commented Jul 3, 2019

miri64 commented Jul 3, 2019

miri64 commented Jul 3, 2019

miri64 commented Jul 3, 2019

MrKevinWeiss left a comment

	gnrc_pktsnip_t gnrc_udp_hdr_build(gnrc_pktsnip_t payload, uint16_t src,
	uint16_t dst)
	{
	assert((src > 0) && (dst > 0));

	src_port.u16 = ctxt->src_port;
	dst_port.u16 = ctxt->dst_port;
	udp = gnrc_udp_hdr_build(buf, src_port.u16, dst_port.u16);

gnrc_tftp: initialize unititialized 'tftp_context_t' #11773

gnrc_tftp: initialize unititialized 'tftp_context_t' #11773

Conversation

miri64 commented Jul 1, 2019

Contribution description

Testing procedure

Issues/PRs references

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MrKevinWeiss left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nmeum Jul 3, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nmeum Jul 3, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miri64 commented Jul 3, 2019

miri64 commented Jul 3, 2019

miri64 commented Jul 3, 2019

miri64 commented Jul 3, 2019

MrKevinWeiss left a comment

Choose a reason for hiding this comment

nmeum Jul 3, 2019 •

edited

nmeum Jul 3, 2019 •

edited