Re: [DNG] [SPAM] Re: May I use Netaid source as an example of good code?

[aitor]

Hi,

On 1/8/21 19:20, aitor wrote:
After that, the suid binary can check _whether or not_ the emited 
signal has been received. If yes, both
the gui and the suid will communicate each other through a unix socket 
or a fifo to know what to do.
Better said, the suid binary can check whether or not the gui has 
handled the signal as expected because
the default behavior of SIGUSR1 (User defined signal 1) is to terminate 
the process. See the table at the

end of the link:

https://en.wikipedia.org/wiki/Signal_(IPC)#POSIX_signals 



I.e., when such a intruder is acting the 
PSTAT_BINARY="SOMEWHERE_DEFINED_NAME" with process ID="PID"

no longer exists.

Aitor.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [SPAM] Re: May I use Netaid source as an example of good code?

[aitor]

On 1/8/21 19:20, aitor wrote:
  /*  trigger the signal handler in order to receive the SIGUSR1 
signal emited by the suid binary */

*emitted*
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [SPAM] Re: May I use Netaid source as an example of good code?

[aitor]

Hi Arnt,

On 1/8/21 17:59, Arnt Karlsen wrote:

I'm looking for a safer way to run the binary with suid permissions
using the shared memory of the system to send a signal.

Time ago somebody said me: "you can do nothing from your binary that
i can't do externally from another binary".

So, am i wasting time?

..nope.


Good :)



Today i've been testing the idea and it's working for me. I'd like to
prepare an example and share with all of you to resolve
vulnerabilities. The example consists of a window with a button (to
run the suid binary) and another binary -the intruder- located in the
same directory and trying to do the same by using the other party's
PID pretending to be the window.

..you're being too damned naive: Why would the intruder not try to
e.g. use your PID?


?

Yes, the intruder would.., of course. And that's what i'm trying to 
avoid. The logic is as follows:


Let's assume the intruder sending our PID. The suid binary receives the 
PID and extracts
the corresponding binary name afterwards. There are other ways, but i'll 
use Jude Nelson's

libpstat for that.

If this name -say PSTAT_BINARY- doesn't match the name of our 
application, then the suid binary

will do nothing. For instance:

if (PSTAT_BINARY == $current_working_dir/app_name) {

    continue;

} else {

    do nothing;

}

Now, you're thinking: "The gui application is already running with the 
above PID. So,

the suid binary will go ahead!"

And here is the key point: the suid binary sends a SIGUSR1 signal to the 
gui application. But
the signal handler associated to this SIGUSR1 is activated within the 
callback function of the button
responsible for running the suid binary, being triggered its default 
signal handling behavior as
soon as the suid binary has been executed. Hence, not reacting to the 
SIGUSR1 signal

events unlessthe user clicks again on the button.


gboolean button_callback ()
{

  /*

    ... run the suid binary asynchronously, going ahead...

 */

  /*  trigger the signal handler in order to receive the SIGUSR1 signal 
emited by the suid binary */


  struct sigaction sa;
  memset(, 0, sizeof(sa));
  sa.sa_handler = sig_handler;
  sa.sa_flags = SA_RESTART | SA_SIGINFO;
  sigemptyset(_mask);
  sigaction(SIGUSR1, , 0);

}

Now, the signal handler will react:

void signal_handler (int signum)
{

if( gtk_main_level() == 0) exit(-1);

/*

    ... here goes the socket ...

 */

  /*   Set to default !!  */

  signal(SIGUSR1, SIG_DFL);

}

After that, the suid binary can check _whether or not_ the emited signal 
has been received. If yes, both
the gui and the suid will communicate each other through a unix socket 
or a fifo to know what to do.


Finally, the suid binary parses the received arguments.

Does it make sense? If not, i may stop here.

Thanks in advance,

Aitor.





___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng