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)
