STATUS_REPARSE on relative CREATE

OSR_Community_User · October 23, 2000, 2:11pm

Hi all,
sorry for sending an attachment here, but looks like the problem
described in the subject line is too serious. Looks like the NT4 bug.
The attachment is the detailed description of it.
Have anybody worked the problem around without doing things like stack
traversing and then patching?

Max

OSR_Community_User · October 23, 2000, 2:37pm

Max,

This is a “well known” problem (I talk about it in my FS class, for
instance) that has been resolved in Windows 2000. In the interim, there’s
really no clean way of which I’m aware to do this (I did know of someone who
patched the stack to fix this bug, but that’s a pretty ugly solution as you
noted…)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Monday, October 23, 2000 2:08 PM
To: File Systems Developers
Subject: [ntfsd] STATUS_REPARSE on relative CREATE

Hi all,
sorry for sending an attachment here, but looks like the problem
described in the subject line is too serious. Looks like the NT4 bug.
The attachment is the detailed description of it.
Have anybody worked the problem around without doing things like stack
traversing and then patching?

Max

OSR_Community_User · October 23, 2000, 2:41pm

> This is a “well known” problem (I talk about it in my FS class, for

instance) that has been resolved in Windows 2000.

I know this.

really no clean way of which I’m aware to do this (I did know of someone
who
patched the stack to fix this bug, but that’s a pretty ugly solution as
you

I did this too - this works. Surely, if some filter will be attached on top
of my redirector, this will fail.

Max

OSR_Community_User · October 24, 2000, 9:56am

Hi Max,
I think I have better solution than your workaround.

PREFACE:

There is prototype of OB_PARSE_METHOD and OBJECT_TYPE_INITIALIZER
in NTIFS.H. Here is prototype of OBJECT_TYPE :

typedef struct _OBJECT_TYPE {
ERESOURCE Mutex;
LIST_ENTRY TypeList;
UNICODE_STRING Name;
LONG DefaultObject;
ULONG Index;
ULONG TotalNumberOfObjects;
ULONG TotalNumberOfHandles;
ULONG HighWaterNumberOfObjects;
ULONG HighWaterNumberOfHandles;
OBJECT_TYPE_INITIALIZER TypeInfo;
ULONG Key;
} OBJECT_TYPE, *POBJECT_TYPE;

NTOSKRNL exports IoFileObjectType.

WORKAROUND:

Your driver should change the (*IoFileObjectType)->TypeInfo.ParseProcedure
to your routine (can be in paged code), which should look like this:
(IopParseFile is your internal variable containing original value from file
object type)

NTSTATUS
MyParseFile (
IN PVOID ParseObject,
IN PVOID ObjectType,
IN OUT PACCESS_STATE AccessState,
IN KPROCESSOR_MODE AccessMode,
IN ULONG Attributes,
IN OUT PUNICODE_STRING CompleteName,
IN OUT PUNICODE_STRING RemainingName,
IN OUT PVOID Context OPTIONAL,
IN PSECURITY_QUALITY_OF_SERVICE SecurityQos OPTIONAL,
OUT PVOID *Object
)
{
NTSTATUS Status;

Status = IopParseFile(ParseObject, …, Object);

if (Status == STATUS_REPARSE)
{
//Now you should zero RelatedFileObject in OPEN_PACKET (+14h)
}

return Status;
}

This is more cleaner than stack traversing because of:

it is generic (and will work also in the case more filters will use it)
offset to OBJECT_TYPE.TypeInfo.ParseProcedure is constant from
NT 3.1 to W2K and probably will remain valid forever (!)
IoFileObjectType will probably remain exported forever

Additionally you can do this workaround only when detecting all below W2K.
For all these versions compatibility is already ensured (and always will).

Paul

OSR_Community_User · October 24, 2000, 11:42am

> This is more cleaner than stack traversing because of:

it is generic (and will work also in the case more filters will use it)

offset to OBJECT_TYPE.TypeInfo.ParseProcedure is constant from
NT 3.1 to W2K and probably will remain valid forever (!)

IoFileObjectType will probably remain exported forever

Maybe. Surely the assignment must be atomic InterlockedExchange.

Max

OSR_Community_User · October 25, 2000, 6:41am

On 10/24/00, ““Maxim S. Shatskih” ” wrote:
> > This is more cleaner than stack traversing because of:
> > - it is generic (and will work also in the case more filters will use it)
> > - offset to OBJECT_TYPE.TypeInfo.ParseProcedure is constant from
> > NT 3.1 to W2K and probably will remain valid forever (!)
> > - IoFileObjectType will probably remain exported forever
>
> Maybe. Surely the assignment must be atomic InterlockedExchange.
>
> Max

Maybe ?
Sure !

Most correct way to do pointer exchange is something like this:

//MyParseFile() is new routine
OB_PARSE_METHOD IopParseFile;

//this should be in some routine
OB_PARSE_METHOD Destination =
&(*IoFileObjectType)->TypeInfo.ParseProcedure;

for(;
{
IopParseFile = *Destination;

if (InterlockedCompareExchange( Destination,
MyParseFile,
IopParseFile ) == IopParseFile) {
break;
}
}

Paul

OSR_Community_User · October 31, 2000, 8:09am

Hi Max,
I think I have better solution than your workaround.

PREFACE:

In NTIFS.H is prototype of OB_PARSE_METHOD and
OBJECT_TYPE_INITIALIZER. Here is prototype of OBJECT_TYPE :

typedef struct _OBJECT_TYPE {
ERESOURCE Mutex;
LIST_ENTRY TypeList;
UNICODE_STRING Name;
LONG DefaultObject;
ULONG Index;
ULONG TotalNumberOfObjects;
ULONG TotalNumberOfHandles;
ULONG HighWaterNumberOfObjects;
ULONG HighWaterNumberOfHandles;
OBJECT_TYPE_INITIALIZER TypeInfo;
ULONG Key;
} OBJECT_TYPE, *POBJECT_TYPE;

NTOSKRNL exports IoFileObjectType.

WORKAROUND:

Your driver should change the
(*IoFileObjectType)->TypeInfo.ParseProcedure
to your routine (can be in paged code), which should look like this:
(IopParseFile is your internal variable containing original value from
file object type)

NTSTATUS
MyParseFile (
IN PVOID ParseObject,
IN PVOID ObjectType,
IN OUT PACCESS_STATE AccessState,
IN KPROCESSOR_MODE AccessMode,
IN ULONG Attributes,
IN OUT PUNICODE_STRING CompleteName,
IN OUT PUNICODE_STRING RemainingName,
IN OUT PVOID Context OPTIONAL,
IN PSECURITY_QUALITY_OF_SERVICE SecurityQos OPTIONAL,
OUT PVOID *Object
)
{
NTSTATUS Status;

Status = IopParseFile(ParseObject, …, Object);

if (Status == STATUS_REPARSE)
{
//Now you should zero RelatedFileObject in OPEN_PACKET (+14h)
}

return Status;
}

Is more cleaner than stack traversing because of:

offset to OBJECT_TYPE.TypeInfo.ParseProcedure is constant from
NT 3.1 to W2K and probably will remain valid forever
IoFileObjectType will probably remain exported forever

Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Monday, October 23, 2000 8:08 PM
To: File Systems Developers
Subject: [ntfsd] STATUS_REPARSE on relative CREATE

Hi all,
sorry for sending an attachment here, but looks like the problem
described in the subject line is too serious. Looks like the NT4 bug.
The attachment is the detailed description of it.
Have anybody worked the problem around without doing things like
stack
traversing and then patching?

Max

OSR_Community_User · October 31, 2000, 8:09am

Hi Max,
I think I have better solution than your workaround.

PREFACE:

In NTIFS.H is prototype of OB_PARSE_METHOD and
OBJECT_TYPE_INITIALIZER. Here is prototype of OBJECT_TYPE :

typedef struct _OBJECT_TYPE {
ERESOURCE Mutex;
LIST_ENTRY TypeList;
UNICODE_STRING Name;
LONG DefaultObject;
ULONG Index;
ULONG TotalNumberOfObjects;
ULONG TotalNumberOfHandles;
ULONG HighWaterNumberOfObjects;
ULONG HighWaterNumberOfHandles;
OBJECT_TYPE_INITIALIZER TypeInfo;
ULONG Key;
} OBJECT_TYPE, *POBJECT_TYPE;

NTOSKRNL exports IoFileObjectType.

WORKAROUND:

Your driver should change the
(*IoFileObjectType)->TypeInfo.ParseProcedure
to your routine (can be in paged code), which should look like this:
(IopParseFile is your internal variable containing original value from
file object type)

NTSTATUS
MyParseFile (
IN PVOID ParseObject,
IN PVOID ObjectType,
IN OUT PACCESS_STATE AccessState,
IN KPROCESSOR_MODE AccessMode,
IN ULONG Attributes,
IN OUT PUNICODE_STRING CompleteName,
IN OUT PUNICODE_STRING RemainingName,
IN OUT PVOID Context OPTIONAL,
IN PSECURITY_QUALITY_OF_SERVICE SecurityQos OPTIONAL,
OUT PVOID *Object
)
{
NTSTATUS Status;

Status = IopParseFile(ParseObject, …, Object);

if (Status == STATUS_REPARSE)
{
//Now you should zero RelatedFileObject in OPEN_PACKET (+14h)
}

return Status;
}

Is more cleaner than stack traversing because of:

offset to OBJECT_TYPE.TypeInfo.ParseProcedure is constant from
NT 3.1 to W2K and probably will remain valid forever (!)
IoFileObjectType will probably remain exported forever

Additionally you can do this workaround only when detecting all below
W2K.
For all these versions compatibility is already ensured (and always
will).

Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Monday, October 23, 2000 8:08 PM
To: File Systems Developers
Subject: [ntfsd] STATUS_REPARSE on relative CREATE

Hi all,
sorry for sending an attachment here, but looks like the problem
described in the subject line is too serious. Looks like the NT4 bug.
The attachment is the detailed description of it.
Have anybody worked the problem around without doing things like
stack
traversing and then patching?

Max

OSR_Community_User · November 14, 2000, 3:56am

I’m not going to run an .EXE off a mailing list. Has anybody run a
virus checker on it?

----- Original Message -----
From: ÀÌÇõ»ó
To: File Systems Developers
Sent: Dienstag, 14. November 2000 04:30
Subject: [ntfsd] STATUS_REPARSE on relative CREATE

Hi all,
sorry for sending an attachment here, but looks like the
problem
described in the subject line is too serious. Looks like the NT4
bug.
The attachment is the detailed description of it.
Have anybody worked the problem around without doing things
like stack
traversing and then patching?

Max

OSR_Community_User · November 14, 2000, 9:44am

This is not Max’s normal e-mail address.

From: xxxxx@safa.co.kr [mailto:xxxxx@safa.co.kr]
Sent: Tuesday, November 14, 2000 2:31 AM
To: File Systems Developers
Subject: [ntfsd] STATUS_REPARSE on relative CREATE

Hi all,
sorry for sending an attachment here, but looks like the problem
described in the subject line is too serious. Looks like the NT4 bug.
The attachment is the detailed description of it.
Have anybody worked the problem around without doing
things like stack
traversing and then patching?

Max

OSR_Community_User · November 14, 2000, 10:07am

The program is probably in spanish language which is
unuseable for most people reading this list.
Next try to make texts for your test programs in english.

The program seems strange to me.
It seems it does some incorectness.

I DO NOT RECOMMEND TO RUN IT !!!

Paul

PS: Hello writer, what the fucking PIG you are ?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-ntfsd-
xxxxx@lists.osr.com]On Behalf Of ???
Sent: Tuesday, November 14, 2000 8:31 AM
To: File Systems Developers
Subject: [ntfsd] STATUS_REPARSE on relative CREATE

Hi all,
sorry for sending an attachment here, but looks like the problem
described in the subject line is too serious. Looks like the NT4 bug.
The attachment is the detailed description of it.
Have anybody worked the problem around without doing things like
stack
traversing and then patching?

Max

OSR_Community_User · November 14, 2000, 10:42am

The PIG at xxxxx@safa.co.kr (from Korea) simply repeated
Maxim S. Shatskih’s message from 23.10.2000 19:08 and
changed the text file attachemet to some king of fucking
program making TROUBLES !!!

I naively ran it and it seems it does something bad with
Windows Explorer so I cannot run any link (.lnk file) and
also I cannot use Start->Run or TaskMan->Run.

This is really bad and all my FUCKINGS goes to Korea !!!

I think this list was not planned for this kind of IDIOTS but
for helping to developers by other developers.

Paul

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-ntfsd-
xxxxx@lists.osr.com]On Behalf Of ???
Sent: Tuesday, November 14, 2000 8:31 AM
To: File Systems Developers
Subject: [ntfsd] STATUS_REPARSE on relative CREATE

Hi all,
sorry for sending an attachment here, but looks like the problem
described in the subject line is too serious. Looks like the NT4 bug.
The attachment is the detailed description of it.
Have anybody worked the problem around without doing things like
stack
traversing and then patching?

Max

OSR_Community_User · November 14, 2000, 10:57am

RE: [ntfsd] STATUS_REPARSE on relative CREATEbtw. This is a PUBLIC mail
list - watch your language!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Hrdina Pavel
Sent: Tuesday, November 14, 2000 10:33 AM
To: File Systems Developers
Cc: xxxxx@safa.co.kr
Subject: [ntfsd] RE: STATUS_REPARSE on relative CREATE
Importance: High

The PIG at xxxxx@safa.co.kr (from Korea) simply repeated
Maxim S. Shatskih’s message from 23.10.2000 19:08 and
changed the text file attachemet to some king of fucking
program making TROUBLES !!!

I naively ran it and it seems it does something bad with
Windows Explorer so I cannot run any link (.lnk file) and
also I cannot use Start->Run or TaskMan->Run.

This is really bad and all my FUCKINGS goes to Korea !!!

I think this list was not planned for this kind of IDIOTS but
for helping to developers by other developers.

Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of ???
Sent: Tuesday, November 14, 2000 8:31 AM
To: File Systems Developers
Subject: [ntfsd] STATUS_REPARSE on relative CREATE

Hi all,
sorry for sending an attachment here, but looks like the problem
described in the subject line is too serious. Looks like the NT4 bug.
The attachment is the detailed description of it.
Have anybody worked the problem around without doing things like stack
traversing and then patching?

Max

OSR_Community_User · November 14, 2000, 11:13am

This is a virus for sure - and the Korean guy who posted it re-sent my
message which was about a month old.

----- Original Message -----
From: “Joe Wein”
To: “File Systems Developers”
Sent: Tuesday, November 14, 2000 11:51 AM
Subject: [ntfsd] Re: STATUS_REPARSE on relative CREATE

> I’m not going to run an .EXE off a mailing list. Has anybody run a
> virus checker on it?
>
> ----- Original Message -----
> From: ÀÌÇõ»ó
> To: File Systems Developers
> Sent: Dienstag, 14. November 2000 04:30
> Subject: [ntfsd] STATUS_REPARSE on relative CREATE
>
>
> Hi all,
> sorry for sending an attachment here, but looks like the
> problem
> described in the subject line is too serious. Looks like the NT4
> bug.
> The attachment is the detailed description of it.
> Have anybody worked the problem around without doing things
> like stack
> traversing and then patching?
>
> Max
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

OSR_Community_User · November 14, 2000, 11:34am

RE: [ntfsd] STATUS_REPARSE on relative CREATE> This is really bad and all my ******** goes to Korea !!!

I think this list was not planned for this kind of IDIOTS but
for helping to developers by other developers.

Maybe he sent the attachment unknowingly - the only real idiot(s) I see here is you who stupidly ran the attachment and then starts complaining when it does something to your machine.

No 1 rule of email: Never execute any attachments sent to you from an unknown source - otherwise you deserve what you get.

If I was you I’d be running some antivirus software right now before you spread the virus any further due to your stupidity. and please watch your language, and if you want to reply send me a message off the list.

Lewis

OSR_Community_User · November 14, 2000, 11:42am

> This is not Max’s normal e-mail address.

Surely, some Korean hacker (with Hieroglyphic name - I’m not even able to
type such names) re-used my old (~a month) message to send a virus here.

Max

OSR_Community_User · November 14, 2000, 11:54am

Effective immediately, we have modified the list software so that it will no
longer forward attachments.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

OSR_Community_User · November 14, 2000, 1:04pm

I think this was not a very fair answer to Hrdina Pavel’s posting.

Sure nobody should run mail attachments from unknown sources. And there may
be also a possibility that someone uses mails from other persons and changes
the attachments unknowingly to a virus. But I doubt this a little bit.

The point in this list is that developers try to help others (and therefore
even opened attachments).

Thanks to OSR (I like those guys) I hope that these sorts of things will be
avoided in the future.

– Reinhard

-----Original Message-----
From: Lewis Cornick [mailto:xxxxx@hotmail.com]
Sent: Dienstag, 14. November 2000 17:30
To: File Systems Developers
Subject: [ntfsd] RE: STATUS_REPARSE on relative CREATE

This is really bad and all my ******** goes to Korea !!!

I think this list was not planned for this kind of IDIOTS but
for helping to developers by other developers.

Maybe he sent the attachment unknowingly - the only real idiot(s) I see here
is you who stupidly ran the attachment and then starts complaining when it
does something to your machine.

No 1 rule of email: Never execute any attachments sent to you from an
unknown source - otherwise you deserve what you get.

If I was you I’d be running some antivirus software right now before you
spread the virus any further due to your stupidity. and please watch your
language, and if you want to reply send me a message off the list.

Lewis

OSR_Community_User · November 14, 2000, 3:52pm

> The point in this list is that developers try to help others (and
therefore

even opened attachments).

No the point is if you are prepared to run attachments from unknown people
without using some virus detection then be prepared for what happens. I know
developers help one another but they should arrange to swap code etc off the
list (most lists treat this in their netiquette guidelines) and be sure in
their own mind that the person is reputable (easy enough to figure out
right?)

Tough - I have no sympathy, sorry been around long enough to know the
basics. Clearly some people haven’t.

Thanks to OSR (I like those guys) I hope that these sorts of things will
be
avoided in the future.

Of course - no offence intended but every other list I’m on has restricted
attachments for a *long* time, long before all these script kiddies even
existed.

And this will be my last message on this subject unless anyone wishes to
discuss it otl - this has gone off topic now.

Lewis

OSR_Community_User · November 16, 2000, 1:39pm

Do not execute the attachment, see
http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=TROJ_NAVIDAD.
A&VSect=T for details.

BH

-----Original Message-----
From: Joe Wein [mailto:xxxxx@gmx.net]
Sent: Tuesday, November 14, 2000 12:52 AM
To: File Systems Developers
Subject: [ntfsd] Re: STATUS_REPARSE on relative CREATE

I’m not going to run an .EXE off a mailing list. Has anybody run a
virus checker on it?

----- Original Message -----
From: AICo"o
To: File Systems Developers
Sent: Dienstag, 14. November 2000 04:30
Subject: [ntfsd] STATUS_REPARSE on relative CREATE

Hi all,
sorry for sending an attachment here, but looks like the
problem
described in the subject line is too serious. Looks like the NT4
bug.
The attachment is the detailed description of it.
Have anybody worked the problem around without doing things
like stack
traversing and then patching?

Max

—
You are currently subscribed to ntfsd as: xxxxx@skydesk.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)