חשוב לציין שלמרות שענקית התוכנה שחררה בחודשיים האחרונים שני תיקונים לחורי אבטחה במנגנון קבצי התמונה WMF, הפרצה הספציפית שעליה מדבר החוקר עדיין לא נסתמה. כך מדווח אתר BetaNews.
"זו לא טעות. לא מדובר בסתם קוד עם באגים. מישהו הכניס את זה במתכוון לחלונות.” כך אמר חוקר האבטחה סטיב גיבסון בשידור הפודקאסט שלו הנקרא "Security now”. “אני מאמין שהאקר כשרוני ופיקח מאוד גילה את הפרצה, התחיל להשתמש בה ומיקרוסופט נתפסה עם המכנסיים למטה: אופס, אנחנו חייבים לסגור את הדלת האחורית הזו". לגיבסון יש גם הוכחה מפורטת לטענה שלו, השוכנת כאן:
קוד:
Subject: Re: You won’t want to miss tonight’s Security Now!, #22
Date: Thu, 12 Jan 2006 18:46:56 -0800
From: Steve Gibson <news2006@grc.com>
[for the unabridged version, see Sam Schinke’s post above]
> There is some interesting discussion of this issue in
> the thread beginning with this post:
>
> http://www.GRC.com/groups/security:108750
>
> Apparently, this function stems from the _very_ early windows
> days and could be used to aid in safely aborting printing,
> or something like that.
All "rendering" of graphical content, whether on screen, in
memory, or to a printer, is done inside if a "device context" or
"DC" in Windows jargon. The Device Context (DC) literally
provides the "context" for the various drawing functions. You
create pens and "select them into" the "context". Or you set
the context’s current foreground color or background color. The
"context" provides a sort of "modal stickiness" for the drawing
functions so that you don’t need to (redundantly) specify the
line width, foreground color, background color, drawing mode,
etc. etc. with each call to drawing functions.
So the Device Context is the "holder" for many current aspects
of the drawing state.
The screen has contexts, metafiles have contexts, and printers
have contexts. When a printing context is handed over to
Windows for printing the app is able to wash its hands of the
"print job" and go on with other things. But what if the user
were to cancel the print job after Windows had "accepted"
responsibility for printing it from the application. Since the
application was officially "done" with the printing, it would
not waiting around for the completion results ... it would be
onto other things -- like perhaps getting the next page setup to
print.
So one of the other things that can be set into a printer’s
Device Context is the address of an application-provided
"callback" -- a subroutine provided by the application that is
expressly designed to asynchronously accept the news and
notification of a printing job being aborted for whatever
reason. Otherwise, there’s no way for Windows to notify the
application.
That is what the "SetAbortProc" system was designed to do.
Originally, this was performed by using a GDI Escape function
with the "subfunction" of "SetAbortProc", then later
"SetAbortProc" was promoted to its own full-blown standard
Windows GDI API call.
Either way, the call to "SetAbortProc" hands Windows a
"pointer" to a subroutine provided by the application and
Windows simply stores that four-byte pointer into the printer’s
device context ... just like it stores the current pen color,
etc.
Now ...
Windows MetaFiles are a completely different sort of animal.
When you create a MetaFile you are actually creating a MetaFile
Device Context that starts out blank. Then, as the GDI
functions in the MetaFile are executed, those GDI drawing
functions are "drawn" or applied onto the Metafile’s Device
Context.
But MetaFiles are not "printed", to do that you need a "printer
Device Context", which is different from screen contexts and
metafile contexts. So it makes no sense to set an abort proc in
a metafile. But even so, there would presumably be no reason
for not allowing an abort proc to be set.
However, this is NOT at all what the WMF processing code does.
What you would expect is that when Windows is reading a WMF
file, and the MetaFile ESCAPE code is encountered, followed by
the SetAbortProc subcode, there would be an argument specifying
a Device Context and a second argument pointing to a user-
provided function that is to be executed in the event of a
printing abort.
But that’s not what happens: When these affected versions of
Windows are reading a WMF file, and the ESCAPE code is
encountered, followed by the SetAbortProc subcode, Windows
simply jumps to the next byte in the file and begin executing
the code found there. Nothing is stored in the Device Context,
no "abort" is awaited.
And, what’s more ... remember my posting yesterday where I said
that I had some initial trouble getting my own tester to trigger
the exploit? The reason for that was the clincher for me, up to
this point: The only way to get this special behavior is to
deliberately mis-set the LENGTH of that ESCAPE/SetAbortProc
metafile record to ONE.
The first four bytes of any metafile record is the length of the
record in two-byte words. My tester was initially setting it to
the correct length for my "exploit" record ... and nothing was
happening. It was only when I deliberately mis-set the record’s
length to exactly ONE -- zero didn’t work, two didn’t work,
nothing else worked ... just ’1’.
But since EVERY METAFILE RECORD starts out with a mandatory
four-byte record length, followed by a two-byte function code,
the smallest possible record is six-bytes, or a size of THREE
words. Therefore the use of a word-length of ONE is impossible.
It was put in there as a safety interlock to prevent the mis-
firing of this backdoor in the event that some whacky metafile
would actually HAVE a needless (because it’s not a printer
device context) Escape/SetAbortProc metafile record.
No...
The only conclusion that can reasonably be drawn is that this
was a deliberate backdoor put into all of Microsoft’s recent
editions of Windows. WHY it was put in and WHO knew about it,
and WHAT they were expected to use it for ... we’ll never know.
--
________________________________________________________________
Steve.
דלת אחורית היא פרצה המושארת על ידי יוצר התוכנה על מנת לקבל גישה חשאית למחשב עליו היא מותקנת, בדומה לסוס טרויאני.
האשמות אלו, וסופת התגובות הנזעמות מצד בלוגרים וגולשים רבים הביאו לכך שסטפן טולוז, ראש מחלקת האבטחה במיקרוסופט נאלץ להגיב בפומבי לדברים ביום שישי. הוא צוטט כאומר כי הפרצה היא פשוט ירושה מגרסאות קודמות של מערכת ההפעלה חלונות (עוד מגרסה 3) וכי לא מדובר בדלת אחורית שהושארה שם במתכוון.
למרות שמיקרוסופט מודה בקיומה של "רגישות קוד", הרי שהיא לא עומדת לתקן את העניין כיוון שהוא לא הוגדר כ”קריטי”. טולוז מסר כי ה"רגישות" אינה ממש מסוכנת וכי "ווקטורי ההתקפה" האפשריים שלה אינם עונים לסטנדרט המחייב את מיקרוסופט לטפל בה. כדי שרגישות כזו תחשב כקריטית ע"י מיקרוסופט, היא חייבת לפתוח פתח לביצוע מתקפה חיצונית אוטומטית שדורשת מעט (או בכלל לא) התערבות מצד המשתמש.
נלקח מכאן:
http://net.nana.co.il/Article/?ArticleID=220126&sid=10
ומכאן:
http://www.grc.com/x/news.exe?cmd=article&group=grc.news.feedback&item=60006