Subj : Re: Tutorial for rookies To : N1uro From : tenser Date : Wed Oct 13 2021 08:00 am On 12 Oct 2021 at 01:25p, N1uro pondered and said... N1> -=> tenser wrote to N1uro <=- N1> N1> te> Bluntly, I don't believe you. With no supporting evidence of the N1> te> existence of these bugs, let alone tracking, this is nothing more N1> te> than typical ham-centric FUD. N1> N1> Is it your policy in life to call those who develop the things you may N1> use a liar? If I ask for some data, and you cannot provide it, then yes, I question your veracity. In particular, if this code is being maintained and the issue in question isn't being effectively tracked, how do you know it hasn't already been fixed? How do you know that the people doing the maintenance are even aware? N1> This is the sort of thing that belongs on facebook. Why not N1> show a bit of appreciation for the things and be proactive rather than N1> point fingers and say hateful things instead. I merely asked you for a pointer to a bug repository where these issues were being tracked. That's not "hateful". You refused to provide any details. Repeated refusals make me wonder if it's really a problem. You might consider showing some appreciation for people who are interested in these things; who knows, they may be able to fix some bugs. N1> te> To be clear, I was hoping for a pointer to a bug tracker. It N1> te> wouldn't be hard to produce patches for something as simple as N1> te> Linux's AX.25 implementation, but without any sort of knowledge N1> te> about what is _actually_ wrong, let alone root cause N1> te> investigation, it's not a good time investment. N1> N1> We -did- submit requests for this to be added to some sort of a bug N1> tracker however the cracks involved are so grave in nature it was N1> decided best not to publish them as to protect the licenses of the hams N1> who may be using such configurations. A full and total take-over of a N1> system can easily be accomplished if the bugs were published. Sounds like security through obscurity to me. Think of this way: what's to prevent a ham from doing this _right now_, since these problems are, as you claim, unsolved upstream. How would that ham _even know_? By your own admission, this isn't even being tracked anywhere. How would they possibly discover the issue? N1> Is this what you promote in your thinking? A strawman argument wrapped in ad hominem hyperbole. N1> te> "Read the archives of my project's mailing list" is not a good N1> te> answer. N1> N1> te> Since you appear to keep shutting that project down on a whim, I'm N1> te> not particularly interested in looking closely at it. Sorry, it's N1> te> just not worth my time to deal with cantankerous folks who don't N1> te> want to work in a spirit of cooperation. N1> N1> Your opinion is quite false in nature. What proof do you have of this? Your own statements that the project is not available on sourceforge because of these kernel issues you continue to talk about. N1> URONode and my other projects are quite alive and in the various N1> repositories. What projects do you have? https://github.com/dancrossnyc/ N1> Besides my own projects I also N1> contribute to the LinFBB project. That's nice...? N1> I pulled my projects off sourceforge N1> until such time as the kernel bugs are fixed. I'm simply tired with N1> receiving emails asking me why my stuff "doesn't work" when I have the N1> only node project available that works on old IBM emulation systems! This seems to directly contradict your statement above that your didn't pull your projects off of sourceforge. N1> When the critical kernel issues are resolved they'll be back on N1> sourceforge as I have upgrades for them all to release. Cool. What guarantee do we have that you won't yank them again? Once you establish a pattern of behavior, users and potential users will recognize it for what it is and react accordingly. This ham won't be running your code and will be advising others not to do so. N1> te> But he didn't actually describe the problem. There was a comment N1> te> saying something about freeing up resources; that was it. No N1> te> description of how the problem manifests itself, what goes wrong, N1> te> the failure mode, etc. There's a one-line patch that was apparently N1> te> never sent to LKML in an older version of the kernel on a random N1> te> web site. N1> N1> No you obviously did not comprehend the NetRom bug issue at all. Well, obviously not. I've been asking for an explanation like that you gave below for what, a week or two now? N1> When a N1> box boots up as fresh, and no users/robots have used the NetRom stack in N1> said box, it will await the 1st connection to which an underlaying ax.25 N1> VIRTUAL CIRCUIT is then created for the NetRom socket to transport N1> through on. That 1st and only that 1st connection will appear to work N1> and be valid. When the session is completed, the underlaying ax.25 layer N1> stays open thus causing the underlaying NetRom socket to be open and N1> available for a remote attacker to attach to and own the box. Finally, something approaching a usable problem report! N1> Marius N1> clearly spells this out in his patches and unlike a 1 line fix as you N1> claim, it's a 4 line patch to insure that the ax.25 virtual circuit gets N1> closed when NetRom is used. Here's the patch: diff -r net/ax25/ax25_subr.c $HOME/ax25-4.19.0-16/ax25_subr.c 290a291,295 > else > { > // YO2LOJ: this is needed for proper NETROM connection cleanup on timeout > ax25_destroy_socket(ax25); > } That's one line of executable code in an "else" branch. The other three lines are brackets and a comment which is extremely generic. No where does any of this "explain" the things that you think it does. N1> Understand now? And if axip/axudp is used, N1> this leaves the IP socket open awaiting any outside resource to connect N1> to it. ....if you allow axip/axudp to the outside world. N1> How can an established connection be in listening or waiting for a N1> connect mode? With such an easy way for a non-ham to attach themself to N1> a box perhaps now you may understand why such bugs are NOT published for N1> the whole world to search. We take tests for our licenses... not to N1> have some packet kiddie take them from us. So like I said, this is security through obscurity. Apparently, a ham could set this up _today_ and have no idea this is such an issue that could cost them their license. N1> This is simply one of many that need attention to. None of which are tracked. Awesome. N1> *raises a vulcan eyebrow* Indeed. --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64) * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101) .