From: antispam@fricas.org   
      
   Dave Froble  wrote:   
   > On 11/12/2025 6:39 PM, Brian Schenkenberger wrote:   
   >> On 2025-11-12 13:04:23 +0000, Dan Cross said:   
   >>>   
   >>> I suspect that there is a lot of business code floating around   
   >>> in memory-unsafe languages (MACRO-32, Pascal, maybe COBOL if   
   >>> used in some odd ways) etc.  Not to mention FFI calls from safe   
   >>> languages into unsafe code.   
   >>   
   >> What *exactly* is memory unsafe using Macro? You do realize that the lion's   
   >> share of VMS is Macro???   
   >>   
   >> — VAXman   
   >>   
   >   
   > Well ....   
   >   
   > From what I've read, Macro-32 is down to 33% or less these days, and   
   shrinking.   
   >   
   > I'm not really sure just what "memory unsafe" means.  Nor is "idiot safe"   
   > something that can be enforced in any language.   
   >   
   > Good code is relatively safe, but not always.  I defy anyone to mention any   
   > language in which I cannot do something stupid.  Might exist, but I can   
   really   
   > be very stupid.   
      
   The point is what happens when you have bugs.  In memory-unsafe languages   
   typically attacker who can control data sent to your program can take   
   control of the program.  Memory-safe languages are supposed to put   
   limits on what can happen.  If say banking program has a bug in withdrawal   
   routine, then attacker may be able to do illegal withdrawals.  But   
   other parts, like authentication, logging, etc, are supposed to   
   work.  So in well designed banking software guilty party will leave   
   traces and there is good chance that law enforement will catch   
   them.  In program written in memory-unsafe language attacker usually   
   can take control of the whole program and say delete logs, change   
   authentication tokens to gain future access or attack something   
   else from "inside", theat is feed malicious date to other programs   
   which are supposed to only get trusted data, so may be easier to   
   break.   
      
   Many years ago I was marginally involved in a security alert.   
   Compiler user reported that compiler was crashing on specific   
   input.  I investigated and tracked problem to generated parser.   
   The parser was table-driven and tables were specific to the   
   compiler.  Driving code ("skeleton") was provided by the parser   
   generator.  This code had to allocate data on parser stack.   
   Logic was rather twisty and on each relevant path skeleton code   
   was supposed to check that there is enough space on the stack.   
   But authors of the skeleton got it wrong in one case: generated   
   paser could access one item beyond the end of area allocated   
   for the stack.  IIRC the check used equality, once you were   
   one item beyond end the check was ineffective.   
      
   I passed info to the maintainers of the parser generator.  In   
   short time security people got involved and there was an alert   
   (CVE).  Security disscussion was in private and I did not see   
   details.  But I learned later that security folks managed to   
   exploit the bug so that using maliciuous data they could gain   
   control of program using generated parser.  Such things are   
   supposed to be impossible in memory-safe language.  That is,   
   when out of memory the program is supposed to reliably crash,   
   without any chance of attacker taking control.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)