home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / aix / 13168 < prev    next >
Encoding:
Text File  |  1993-01-09  |  3.6 KB  |  109 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!geraldo.cc.utexas.edu!portal.austin.ibm.com!awdprime.austin.ibm.com!greenber.austin.ibm.com!jfh
  3. From: jfh@greenber.austin.ibm.com (John F Haugh II)
  4. Subject: Re: process numbers
  5. Sender: news@austin.ibm.com (News id)
  6. Message-ID: <C0Ly9M.nB6@austin.ibm.com>
  7. Date: Sat, 9 Jan 1993 22:24:58 GMT
  8. References: <BzMqs8.1Krz@austin.ibm.com> <1h6hv0INNrsl@life.ai.mit.edu> <C0EB6D.174w@austin.ibm.com>
  9. Organization: AIX Software Support, Austin, Republica de Tejas
  10. Lines: 97
  11.  
  12. In article <C0EB6D.174w@austin.ibm.com> dcm@codesmith.austin.ibm.com (Craig Miller - dcm@austin.ibm.com) writes:
  13. >In article <1h6hv0INNrsl@life.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
  14. >>
  15. >>In article <BzMqs8.1Krz@austin.ibm.com> curt@ekhadafi.austin.ibm.com
  16. >>(Curt Finch 903 2F021 curt@aixwiz.austin.ibm.com 512-838-2806) writes:
  17. >>>
  18. >>> My understanding is that it was done for security reasons.
  19. >>
  20. >>This is nonsense.
  21. >
  22. >    Uh, wait a minute Charles...  Many moons ago during the
  23. >    early development days of AIX, there was a rumor circulating
  24. >    around AIX development that generating sequential pids was
  25. >    a security hole.  I think the phrase used was "covert channel".
  26.  
  27. Craig wins the prize.
  28.  
  29. The process ID is a covert storage channel.  If AIX used sequential
  30. pids two co-operating processes could pass information back and forth
  31. to each other with the following little piece of code -
  32.  
  33.  
  34.     send_one_bit ()
  35.     {
  36.         int    i;
  37.  
  38.         for (i = 0;i < 100;i++)
  39.             if (fork () > 0)
  40.                 continue;
  41.             else
  42.                 exit (0);
  43.  
  44.         sleep (1);
  45.     }
  46.  
  47.     send_zero_bit ()
  48.     {
  49.         sleep (1);
  50.     }
  51.  
  52.     receive_bit ()
  53.     {
  54.         if ((first_pid = fork ()) == 0)
  55.             exit (0);
  56.  
  57.         sleep (1);
  58.  
  59.         if ((second_pid = fork ()) == 0)
  60.             exit (0);
  61.  
  62.         return (second_pid - first_pid >= 100);
  63.     }
  64.  
  65. Throw some signal analysis and error correcting code in there and you
  66. have your basic covert channel.  You could even use start and stop bits
  67. and decode the data like it was coming in over an RS-232 line at 1 baud ...
  68.  
  69. >    Perhaps that has changed since, but saying that anything
  70. >    Curt says is "nonsense" is going a bit overboard, don't you
  71. >    think?  He was in AIX development back then.  Were you?
  72.  
  73. Probably not ;-), but then I was in the department that actually dreamed
  74. that one up.  Curt isn't saying anything nonsensical ...
  75.  
  76. >>The process number is the process table index shifted 8 bits, plus a
  77. >>number which is incremented every time a process is put in that slot.
  78. >
  79. >    True.  But this doesn't prove that Curt's statement is wrong.
  80. >    AIX still doesn't generate sequential pids.
  81.  
  82. Actually, you can still play games with covert channels using the program
  83. I typed in above.  This time, add the lines
  84.  
  85.     first_pid &= 0xff;
  86.     second_pid &= 0xff;
  87.  
  88. before the "return" statement and throw some other code in there to deal
  89. with wrap around.  Same old covert channel, just slightly harder to use.
  90.  
  91. If you look at the PIDs you will see that the last byte is sequential.
  92.  
  93. >>This is actually fairly useful.  When I want to spy on a process with
  94. >>`crash', it's easy to calculate the index into the process table which
  95. >>I need for the `u' command.
  96. >
  97. >    I always looked at the output from the 'proc' subcommand, then
  98. >    used the slot number for 'u'.....
  99.  
  100. Charles is right on this one.
  101.  
  102. % expr PID / 256
  103.  
  104. is a LOT easier than wading through hundreds of lines of output from "proc".
  105. -- 
  106. John F. Haugh II      | Quality is ... knowing who |  MaBellNet: (512) 823-8817
  107. SneakerNet: 042/2F068 | your customer is and what  |      VNET: HAUGH at AUSVM8
  108. [ DoF #17 ] [ TSAKC ] | your customer wants.       |  Disc: I speak 4 me, !IBM.  
  109.