<<< DOCD$:[NOTES$LIBRARY]SCT-RAVEN.NOTE;1 >>> -< The SCT Raven conference >- ================================================================================ Note 351.0 Adjust fixup block TO line offsets No replies EVMS::CDONAT 242 lines 17-MAR-1997 15:02 -------------------------------------------------------------------------------- Project: MAIL UI Project Leader: Carey Donat Inspected or Reviewed by: Aswin Kumar (STAR::ASWIN) Development Stream: RAVEN-FT1 Checkin Type: BugFix Problem Symptom: The TO line in a received message can become so skewed that passwords for remote distribution lists may be visible. Diagnosis: A fixup block is generated for each address in the TO line that contains a node name, and is primarily used for password masking. Each fixup block contains both a starting and an ending address for the position in the TO line of the string that will be replaced, based on the original contents of the TO line descriptor pointer. When these blocks are processed, the TO line serves as both source and destination strings for a call to STR$REPLACE. While the address of the TO line does not change, the contents of the TO line's descriptor pointer is changed by STR$REPLACE to point to the now changed string. All is well for a single call to STR$REPLACE, but the offsets into the TO line (stored in the fixup block) for subsequent calls are stale, because they reference positions in a TO string that that is no longer being used by STR$REPLACE, and have not been adjusted for the net size of the change made by the previous call. The biggest danger is to a remote distribution list at the tail of a relatively long TO list; the begin/end addresses for the string to be replaced are so off, that the password portion of the distribution list file specification is never changed. This does not affect delivery of the message; it is part of post-recipient validation/connection, pre-delivery message processing of TO line formatting. Cure: Store the TO line's descriptor pointer before any calls to STR$REPLACE, so that the addresses (representing offsets) in the fixup blocks remain meaningful. Calculate the net change to the TO line caused by a call to STR$REPLACE, and apply it to the offsets into the TO string for the next call. Platforms affected: VAX and ALPHA Modules: [MAILSHR]MAILPARSE.B32 Affected Images: SYS$COMMON:[SYSEXE]MAIL_OLD.EXE PLEASE NOTE THAT EVEN THOUGH THIS IS A FIX TO THE "OLD" MAIL UI, WE STILL SHIP THIS IMAGE. Impact/Risks: The risk of this change is minimal; the impact is great because explicit passwords can be exposed to message recipients. How this change was Tested: I built a private debug version of MAIL_OLD.EXE and watched the iterative string replacements done both before and after the code change. BEFORE: TO string as I entered it (split for readability): MAIL> SEND To: @vmsspt"donat booksbooksbooks"::work3:[donat]a.dis, @vmsspt"donat booksbooksbooks"::work3:[donat]b.dis, @vmsspt"donat booksbooksbooks"::work3:[donat]c.dis TO string in the message I received (split after the first dist list file name for readability): From: STAR::CDONAT "VMS Sustaining Engineering" To: VMSSPT"donat password"::VMSSPT"donat password"::@VMSSPT"donat password"::WORK3:[DONAT]A.DIS, @VMSSPT"donat booksbooksbooks"::WORK3:[DONAT]B.DIS, @VMSSPT"donat booksbooksbooks"::WORK3:[DONAT]C.DIS CC: CDONAT Subj: test mail This message was successfully delivered; the 1st address is skewed, 2nd and 3rd addresses have exposed passwords AFTER: TO string as I entered it (split for readability): MAIL> send To: @vmsspt"donat booksbooksbooks"::work3:[donat]a.dis, @vmsspt"donat booksbooksbooks"::work3:[donat]b.dis, @vmsspt"donat booksbooksbooks"::work3:[donat]c.dis TO line on received message (again split for readability): #1 20-FEB-1997 09:37:08.02 NEWMAIL From: STAR::CDONAT "VMS Sustaining Engineering" To: @VMSSPT"donat password"::WORK3:[DONAT]A.DIS, @VMSSPT"donat password"::WORK3:[DONAT]B.DIS, @VMSSPT"donat password"::WORK3:[DONAT]C.DIS CC: CDONAT Subj: test Again, the message was successfully delivered; this time all addresses formatted correctly. Associated QARs,CLDs,SPRs: None; I was contacted via mail by Jim Lanciani on behalf of Bill Matthews who had experienced the problem on node OPNDCE. (Optional) Comments: Diff listing attached (Optional) Special Build Instructions: None ************ File WORK9:[CDONAT]MAILPARSE.RAVEN_FT1_ORIG;1 2 MODULE mail$parse (IDENT = 'X-10' 3 ) = ****** File WORK9:[CDONAT]MAILPARSE.B32;3 2 MODULE mail$parse (IDENT = 'X-11' 3 ) = ************ ************ File WORK9:[CDONAT]MAILPARSE.RAVEN_FT1_ORIG;1 43 ! ****** File WORK9:[CDONAT]MAILPARSE.B32;3 43 ! X-11 CCD061 Carey Donat 17-Mar-1997 44 ! MAIL$$PARSE_STRING: adjust offsets in fixup blocks into TO string 45 ! when STR$REPLACE is called recursively on TO string for access control 46 ! string replacement 47 ! ************ ************ File WORK9:[CDONAT]MAILPARSE.RAVEN_FT1_ORIG;1 924 status; 925 926 ! ****** File WORK9:[CDONAT]MAILPARSE.B32;3 928 status, 929 offset_adjust : LONG INITIAL (0), 930 orig_string_ptr : LONG INITIAL (0), 931 new_string_length : VECTOR[2,WORD] INITIAL (0); 932 933 ! ************ ************ File WORK9:[CDONAT]MAILPARSE.RAVEN_FT1_ORIG;1 957 ! 958 ! Process all access control string fixup sections ****** File WORK9:[CDONAT]MAILPARSE.B32;3 964 965 ! 966 ! save the original TO string ptr for fixup block offset calculations 967 ! 968 orig_string_ptr = .to_string[DSC$A_POINTER]; 969 970 ! 971 ! Process all access control string fixup sections ************ ************ File WORK9:[CDONAT]MAILPARSE.RAVEN_FT1_ORIG;1 962 start_position = .queue_entry[4] - .to_string[DSC$A_POINTER] + 1; 963 end_position = .queue_entry[5] - .to_string[DSC$A_POINTER] + 1; 964 STR$REPLACE(.to_string, ! Dest string 965 .to_string, ! Source string 966 start_position, ! Start-pos 967 end_position, ! End-pos 968 queue_entry[2]); ! Replacement string 969 STR$FREE1_DX(queue_entry[2]); 970 IF_ERR(LIB$FREE_VM(%REF(4*6),queue_entry);, 971 RETURN .status); 972 END; ****** File WORK9:[CDONAT]MAILPARSE.B32;3 975 ! 976 ! queue_entry[4] contains the address of the beginning of the string to be 977 ! replaced within the TO list, but is relative only to the original TO list 978 ! descriptor pointer, not the TO list descriptor that exists after a call to 979 ! STR$REPLACE; also adjust the start_positon offset for the net change from 980 ! the last replacement. 981 ! 982 983 start_position = (.queue_entry[4] - .orig_string_ptr + 1) - .offset_adjust; 984 985 ! same for end_position 986 end_position = (.queue_entry[5] - .orig_string_ptr + 1) - .offset_adjust; 987 988 STR$REPLACE(.to_string, ! Dest string 989 .to_string, ! Source string 990 start_position, ! Start-pos 991 end_position, ! End-pos 992 queue_entry[2]); ! Replacement string 993 994 ! calculate the net change to the TO string size by subtracting the size of the 995 ! string used for the replacement (new string) from the size of the string that 996 ! was replaced (original string) 997 998 new_string_length = .queue_entry[2]; 999 offset_adjust = (((.queue_entry[5] - .queue_entry[4]) - .new_string_length[0]) + 1); 1000 1001 STR$FREE1_DX(queue_entry[2]); 1002 IF_ERR(LIB$FREE_VM(%REF(4*6),queue_entry);, 1003 RETURN .status); 1004 END; ************ Number of difference sections found: 5 Number of difference records found: 46 DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=WORK9:[CDONAT]MAILPARSE.DIFF;1- WORK9:[CDONAT]MAILPARSE.RAVEN_FT1_ORIG;1- WORK9:[CDONAT]MAILPARSE.B32;3