Subj : Re: Tutorial for rookies
To : tenser
From : N1uro
Date : Wed Oct 13 2021 12:07 am
tenser;
-=> tenser wrote to N1uro <=-
te> On 12 Oct 2021 at 01:25p, N1uro pondered and said...
te> If I ask for some data, and you cannot provide it, then yes,
te> I question your veracity. In particular, if this code is being
te> maintained and the issue in question isn't being effectively
te> tracked, how do you know it hasn't already been fixed? How do
te> you know that the people doing the maintenance are even aware?
You've asked for data and I've done what I could and beyond to provide it.
I know who's maintaining the code in question as we email amongst ourselves.
We all share code. I know some code has been fixed, some yet has been fixed.
I'm hoping by year end it'll all be fixed.
te> I merely asked you for a pointer to a bug repository where these
te> issues were being tracked. That's not "hateful". You refused
te> to provide any details. Repeated refusals make me wonder if it's
te> really a problem.
I have not refused answers. Specific details perhaps because of the fact
that it's not a good idea to let non-hams have information on how to exploit
ham boxes. You want these published however to which I can not understand
for the life of me why. I did point you to a more current archive of linux-hams
which you claimed did not exist.
te> You might consider showing some appreciation for people who are
te> interested in these things; who knows, they may be able to fix
te> some bugs.
If you emailed me privately we could get into more details. In a public echo
area is not the place to discuss these things. I do appreciate those who use
such things, often it's me that gets the disrepect and frankly I grow tired
of it.
te> Sounds like security through obscurity to me. Think of this way:
te> what's to prevent a ham from doing this _right now_, since these
te> problems are, as you claim, unsolved upstream. How would that ham
te> _even know_? By your own admission, this isn't even being tracked
te> anywhere. How would they possibly discover the issue?
Publically it's not tracked. Privately yes. Many ham projects are tracked
securely via obscurity. Why would I have a reason to say that sockets are
left open if it's not true? In what way(s) would I gain any benefit either
way? Zero!
te> Your own statements that the project is not available on
te> sourceforge because of these kernel issues you continue to
te> talk about.
Those who have used my software for the 20+ years it's been around know
me and know I would help them out. I don't want any new users at this time
but will help those who do grab it using apt or dnf to install them with. 95%
however when faced with having to compile a kernel or patch a kernel usually
will flee back to DOS. I am also in very poor health and don't wish to be
bothered by those who aren't willing to take the steps needed. Those who
do use my software will wait quite patiently for the projects to be reposted
with the upgrades in them. I'm not concerned.
te>
https://github.com/dancrossnyc/
Ahh now I know who you are. I assigned you your block and maintain your
ampr DNS. Considering the level of integrity I gave you to get you up and
running on 44-net, what reason did I offer you to prove not to believe me?
Again, I have nothing to gain either way here.
N1> Besides my own projects I also
N1> contribute to the LinFBB project.
te> That's nice...?
You could always also look inside the tickets of LinFBB on the afore mentioned
issues. F6BVP and his crew supplied ROSE patches as the URONode crew has
supplied NetRom fixes. Others have supplied various fixes to various codes.
Some have to do with the ax25 libs some with the kernel protocol stack.
The ones I personally am most concerned about are the 6-pack and NetRom
bugs.
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!
te> This seems to directly contradict your statement above that your
te> didn't pull your projects off of sourceforge.
I -said- I pulled them off, however various distros still have the software
in their repositories.
te> Cool. What guarantee do we have that you won't yank them again?
te> Once you establish a pattern of behavior, users and potential
te> users will recognize it for what it is and react accordingly.
I have announced that once the issues are fixed they'll be back. My
core base knows that I'll hold true to my word. Hopefully the stack issues
once fixed will remain fixed TFN. It seems as if some of these bugs have
been in existence since the 1990s however just weren't noticed until more
recently probably due to compiler instructions I'll guess.
te> This ham won't be running your code and will be advising others
te> not to do so.
So you will cause defamation of my code? Under the grounds it does not work
I presume? While I'm quite happy you will not be running my software, and
while it's available from various distributions repositories, under what
grounds will you be advising people not to use it?
te> Well, obviously not. I've been asking for an explanation like that
te> you gave below for what, a week or two now?
I've stated several times, the socket is left open. As you know an open
unused socket can easily be grabbed onto remotely by an attacker.
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.
te> Finally, something approaching a usable problem report!
I've stated this several times.
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.
te> Here's the patch:
te> diff -r net/ax25/ax25_subr.c $HOME/ax25-4.19.0-16/ax25_subr.c
te> 290a291,295
> else
> {
> // YO2LOJ: this is needed for proper NETROM connection cleanup on
timeout
> ax25_destroy_socket(ax25);
> }
te> That's one line of executable code in an "else" branch. The other
te> three lines are brackets and a comment which is extremely generic.
te> No where does any of this "explain" the things that you think it
te> does.
It's perfectly clear to me that without the above, NetRom "cleanup" or proper
socket closure does not occur leaving it in an open state
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.
te> ...if you allow axip/axudp to the outside world.
Have you seen most ham boxes? I'd safely say 95% of them do. You're not far
from me... the average age of a ham is 70. Most hams I know don't even believe
in passwords at all anywhere ham or internet usage! As I said recently to one
developer, it's more or less up to us to help secure these guys in our code
as best we can. While he disagreed with my statement he did end up doing so.
te> So like I said, this is security through obscurity. Apparently,
te> a ham could set this up _today_ and have no idea this is such an
te> issue that could cost them their license.
Possible, but not quite probable. It added to my decision to pull my
projects offline since my installer SVNs from SF.net. Many don't know
my stuff is in the linux repos... which is fine by me. Sometimes obscurity
is a better way to execute security. Maybe not in all cases but under certain
circumstances yes.
N1> This is simply one of many that need attention to.
te> None of which are tracked. Awesome.
not necessarily publically no... but tracked yes.
--- MultiMail/Linux v0.52
* Origin: Carnage - risen from the dead now on SBBS (21:4/107)
