dualbus

[...] you don't actually need to verify agains a user's secret immediately, you simply need to check that the token is valid using the app secret. The subset of valid tokens that you need to check is much smaller than the universe of all the unexpired tokens your application has issued.

What you are describing here is different than what is described in the blog post that you linked to.

Please look at the definition of the function 'validateToken'. In particular, notice how 'getUser' function (which the author notes issues a DB query) is called for every JWT with a valid signature!

EDIT: I failed to realize that you are the author of the blog post. Still my point stands, in that your description doesn't match what the code does.

Apologies for being dense. Could you spell out how you went from Paragon Solutions to the Signal Protocol?

On DJT: Donald John Trump.

Yes, I got a "Reset password instructions" email from support@bugcrowd.com at roughly 11:13 PM UTC. There is no information in the email nor the linked page about why it is necessary.

How am I supposed to trust this...

Bash accepts both variants of the equality operator. So it is not a bug.

I literally can't make heads or tails of the risk here. All I see is the very alarming and scary words "backdoor" and "ssh server" in the same sentence.

From what I've read, there is still lots of unknowns about the scope of the problem. What has been uncovered so far indicates it involves bypassing authentication in SSH.

In https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b..., Sam James points out

If this payload is loaded in openssh sshd, the RSA_public_decrypt function will be redirected into a malicious implementation. We have observed that this malicious implementation can be used to bypass authentication. Further research is being done to explain why.

Thus, an attacker maybe could use this to connect to vulnerable servers without needing to authenticate at all.

You mean like Ksh's discipline functions?

  dualbus@system76-pc:~$ ksh -c 'date=; date.get() { .sh.value=$(date +%s); }; echo $date; sleep 5; echo $date'
  1546926637
  1546926642

Awesome, thank you! This is super useful. I stand corrected.

I tried python, bash and even C, none of them update /proc/self/comm when argv[0] is updated:

  dualbus@system76-pc:~$ cat argv0.c
  #include <stdio.h>
  #include <string.h>
  int main(int argc, char **argv) {
      FILE *fp;
      char buf[256]; // XXX :-)
      strcpy(argv[0], "XYZ");
      //puts(argv[0]);
      fp = fopen("/proc/self/comm", "r");
      fread(&buf, 1, 256, fp);
      buf[255] = '\0';
      puts(buf);
  }
  dualbus@system76-pc:~$ gcc -o argv0 argv0.c  -Wall
  dualbus@system76-pc:~$ ./argv0
  argv0

  dualbus@system76-pc:~$ python -c 'import sys; sys.argv[0] = "XYZ"; print(open("/proc/self/comm").read())'
  python

  dualbus@system76-pc:~$ ~/src/gnu/bash/bash -c 'BASH_ARGV0="XYZ"; cat /proc/$BASHPID/comm'
  bash

  > 3.6   /proc/<pid>/comm  & /proc/<pid>/task/<tid>/comm
  > --------------------------------------------------------
  > These files provide a method to access a tasks comm value. It also allows for
  > a task to set its own or one of its thread siblings comm value. The comm value
  > is limited in size compared to the cmdline value, so writing anything longer
  > then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated
  > comm value.

  dualbus@system76-pc:~$ ~/src/gnu/bash/bash -c 'echo -n XYZ > /proc/$BASHPID/comm; ps -p $BASHPID'
    PID TTY          TIME CMD
  28797 pts/6    00:00:00 XYZ

EDIT: formatting.

EDIT2: I stand corrected, see willglynn's comment.

Can you show an example of how this would work with BASH_ARGV0?

The built-in replacements run in the same process as the Bash shell, and thus, avoid the fork/exec system calls.

It's a minor performance optimization that might be useful if you're doing thousands of rm's or stat's in a script.

I would like to understand how this would work.

argv is a buffer in Bash's process memory space. This is AFAIK, not shared in any way with the kernel.

How would the kernel know that a process wrote to the memory location of argv[0] and then reflect that in /proc?

This is what I tried:

  dualbus@system76-pc:~/src/gnu/bash$ ./bash -c 'echo $BASH_VERSION; ps -p $BASHPID -f; BASH_ARGV0=NOT-BASH; echo $0; ps -p $BASHPID -f; (ps -p $BASHPID -f && : do not optimize fork)'
  5.0.0(1)-rc1
  UID        PID  PPID  C STIME TTY          TIME CMD
  dualbus  27918 20628  0 20:16 pts/5    00:00:00 ./bash -c echo $BASH_VERSION; ps -p $BASHPID -f; BASH_ARGV0=NOT-BASH; echo $0; ps -p $BASHPID -f; (ps -p $BASHPID -f && : do not optimize fork)
  NOT-BASH 
  UID        PID  PPID  C STIME TTY          TIME CMD
  dualbus  27918 20628  0 20:16 pts/5    00:00:00 ./bash -c echo $BASH_VERSION; ps -p $BASHPID -f; BASH_ARGV0=NOT-BASH; echo $0; ps -p $BASHPID -f; (ps -p $BASHPID -f && : do not optimize fork)
  UID        PID  PPID  C STIME TTY          TIME CMD
  dualbus  27921 27918  0 20:16 pts/5    00:00:00 ./bash -c echo $BASH_VERSION; ps -p $BASHPID -f; BASH_ARGV0=NOT-BASH; echo $0; ps -p $BASHPID -f; (ps -p $BASHPID -f && : do not optimize fork)

I don't think changing argv[0] in the current process will have any effect in the /proc file system.

And to do what you describe, there's `exec -a NAME' already:

  $ (exec -a NOT-BASH bash -c 'echo $0; ps -p $BASHPID -f')
  NOT-BASH
  UID        PID  PPID  C STIME TTY          TIME CMD
  dualbus  18210  2549  0 19:30 pts/1    00:00:00 NOT-BASH -c echo $0; ps -p $BASHPID -f

Chet Ramey.

He is the maintainer of the GNU Bash shell and of the GNU Readline line-editing library.

* https://tiswww.case.edu/php/chet/

* https://www.red-gate.com/simple-talk/opinion/geek-of-the-wee...

[1]: "${foo} bar baz" v.s. "$foo"" bar baz"

Why would you quote the second option like that? You can just write: "$foo bar baz"

will be surprised that [[ "foo" == "f*" ]] does pattern matching

It will not do pattern matching, because you quoted the right-hand side.

I recently bought an HP laptop which has a AMD A10-8700P APU and was very surprised to find out that basic display functionality is very glitchy under Linux (backlight would flicker, or in some cases it wouldn't work at all). I tried with Debian unstable first, then with Ubuntu (17.04 and now 17.10) and none of the vanilla kernels in these distros worked for me (with the amdgpu driver, ), so I'm now running 4.9.51+ from https://github.com/M-Bab/linux-kernel-amdgpu-binaries (the most recent versions crash when I use HDMI output).

You can read more about it in:

* https://www.reddit.com/r/linux/comments/6m2jvn/eli5_of_amd_d...

* https://www.reddit.com/r/linux/comments/754uh6/update_on_dcd...

* https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-1...

* https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-D...

x[:4].lower() = 'test' ?