Policy question

[Myria]

Should ReactOS copy unnecessary restrictions that Windows has?

The example I'm thinking of is NtSetLdtEntries.  In Windows NT (and 
currently ReactOS as well), this function will not let you create an LDT 
entry whose limit is above the user/kernel barrier.  This restriction sounds 
like it was made with security in mind, but it doesn't affect security.  The 
processor's page table will already block access to kernel memory no matter 
what selector you use.  After all, the default user CS and DS already have a 
limit of FFFFFFFF.

Should such a problem be fixed?

Fireball said "no, unless some 3rd party app or driver depends on them" when 
I asked about whether such restrictions should be copied.  Pretty much the 
only thing using NtSetLdtEntries is NTVDM, and this restriction already 
causes some DOS programs to break that would otherwise work.  (Such programs 
are usually setting selectors that wrap the address space.)

Melissa

[Alex Ionescu]

Myria wrote:
>   Should ReactOS copy unnecessary restrictions that
> Windows has? 
You're not an NT designer. Just because you find something "unnecessary"
doesn't mean it is. Have you emailed anyone at Microsoft to verify your
theory, before potentially creating a security hole?

>   
>  The example I'm thinking of is NtSetLdtEntries.  In Windows NT (and 
>  currently ReactOS as well), this function will not let you create an LDT 
>  entry whose limit is above the user/kernel barrier. 
>  This restriction sounds 
>  like it was made with security in mind, but it doesn't affect security.   
Then I would venture to guess that the internationally recognized and
distinguished engineers, professors and developers originally assigned
with the NT project didn't think of security.

>   The 
>  processor's page table will already block access to kernel memory no matter 
>  what selector you use.  After all, the default user CS and DS already have a 
>  limit of FFFFFFFF.
>  
>  Should such a problem be fixed? 
We don't even know if it's a problem yet. As of now, it's an assumption.

>   
>  Fireball said "no, unless some 3rd party app or driver depends on them" when 
>  I asked about whether such restrictions should be copied.  Pretty much the 
>  only thing using NtSetLdtEntries is NTVDM, and this restriction already 
>  causes some DOS programs to break that would otherwise work.  (Such programs 
>  are usually setting selectors that wrap the address space.) 
The decision was made a long time ago not to export additional APIs or
provide extra functionality which would cause programs to work on
ReactOS but not Windows. This creates a dangerous slippery slope. Not
being compatible doesn't only mean "not having all the features", it
also means "having more features". Once ROS DLLs/programs/3rd-party
applications start depending on ReactOS, you break compatibility. You
also start breaking the DDK license.

But even before getting to this line of thought, I ask again. Have you
verified this allegation?

>   
>  Melissa 
>   
Best regards,
Alex Ionescu

[Myria]

Uhh, it's called a disassembly and the x86 manuals.  Attempting to access 
kernel memory through 0xC0000000 in the normal DS segment is no different to 
an x86 than accessing kernel memory through another segment at 0x00000000 in 
a custom segment whose base is 0xC0000000.  Both are going to fail because 
the page table says those are kernel addresses.  Since the default CS and DS 
already have the limit as FFFFFFFF, there isn't a risk from a different 
segment having the same values.

The only risk becomes the syscall and interrupt handlers.  The first thing 
these do is load all the segment registers with proper values, before trying 
to read from memory.  So these aren't an issue either.  (CS and SS were 
already loaded by the CPU.)

It wasn't that the designers didn't think about security, it's that they 
thought *too much* about security.  They saw a risk when there really wasn't 
one.  They just never noticed because they didn't care - NTVDM is basically 
unsupported now.

Several years ago, I ran into several DOS programs that failed to run under 
NTVDM solely because they were creating selectors that wrapped the address 
space, so yes, a compatibility problem does exist.

ReactOS already allows NtCreateSection with SEC_IMAGE on an ELF file, which 
is much more of an extra feature than deleting an unnecessary security 
check.

Melissa

----- Original Message ----- 
From: "Alex Ionescu" <ionucu(a)videotron.ca>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: Sunday, June 04, 2006 13:23
Subject: Re: [ros-dev] Policy question


>   Myria wrote:
> >   Should ReactOS copy unnecessary restrictions that
> > Windows has? 
>  You're not an NT designer. Just because you find something "unnecessary"
>  doesn't mean it is. Have you emailed anyone at Microsoft to verify your
>  theory, before potentially creating a security hole?
>
> >  
> >  The example I'm thinking of is NtSetLdtEntries.  In Windows NT (and
> >  currently ReactOS as well), this function will not let you create an LDT
> >  entry whose limit is above the user/kernel barrier.
> >  This restriction sounds
> >  like it was made with security in mind, but it doesn't affect security. 
>  Then I would venture to guess that the internationally recognized and
>  distinguished engineers, professors and developers originally assigned
>  with the NT project didn't think of security.
>
> >   The
> >  processor's page table will already block access to kernel memory no 
> >  matter
> >  what selector you use.  After all, the default user CS and DS already 
> >  have a
> >  limit of FFFFFFFF.
> >
> >  Should such a problem be fixed? 
>  We don't even know if it's a problem yet. As of now, it's an assumption.
>
> >  
> >  Fireball said "no, unless some 3rd party app or driver depends on them" 
> >  when
> >  I asked about whether such restrictions should be copied.  Pretty much 
> >  the
> >  only thing using NtSetLdtEntries is NTVDM, and this restriction already
> >  causes some DOS programs to break that would otherwise work.  (Such 
> >  programs
> >  are usually setting selectors that wrap the address space.) 
>  The decision was made a long time ago not to export additional APIs or
>  provide extra functionality which would cause programs to work on
>  ReactOS but not Windows. This creates a dangerous slippery slope. Not
>  being compatible doesn't only mean "not having all the features", it
>  also means "having more features". Once ROS DLLs/programs/3rd-party
>  applications start depending on ReactOS, you break compatibility. You
>  also start breaking the DDK license.
>
>  But even before getting to this line of thought, I ask again. Have you
>  verified this allegation?
>
> >  
> >  Melissa
> >  
>  Best regards,
>  Alex Ionescu
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Marc Schütz]

>   -------- Original-Nachricht --------
>  Datum: Sun, 4 Jun 2006 14:30:35 -0700
>  Von: Myria <myriachan(a)cox.net>
>  An: ReactOS Development List <ros-dev(a)reactos.org>
>  Betreff: Re: [ros-dev] Policy question
>  
>  Uhh, it's called a disassembly and the x86 manuals.  Attempting to access 
>  kernel memory through 0xC0000000 in the normal DS segment is no different
>  to 
>  an x86 than accessing kernel memory through another segment at 0x00000000
>  in 
>  a custom segment whose base is 0xC0000000.  Both are going to fail because
>  the page table says those are kernel addresses.  Since the default CS and
>  DS 
>  already have the limit as FFFFFFFF, there isn't a risk from a different 
>  segment having the same values.
>   
This is only true for accesses from user mode. Are you sure that at no point, esp.
somewhere in the APIs concerning VDMs, such a segment descriptor could be used from within
the kernel?

>   The only risk becomes the syscall and interrupt
> handlers.  The first thing
>  these do is load all the segment registers with proper values, before
>  trying 
>  to read from memory.  So these aren't an issue either.  (CS and SS were 
>  already loaded by the CPU.)
>  
>  It wasn't that the designers didn't think about security, it's that they 
>  thought *too much* about security.  They saw a risk when there really
>  wasn't 
>  one.  They just never noticed because they didn't care - NTVDM is
>  basically 
>  unsupported now.
>  
>  Several years ago, I ran into several DOS programs that failed to run
>  under 
>  NTVDM solely because they were creating selectors that wrapped the address
>  space, so yes, a compatibility problem does exist.
>  
>  ReactOS already allows NtCreateSection with SEC_IMAGE on an ELF file,
>  which 
>  is much more of an extra feature than deleting an unnecessary security 
>  check.
>  
>  Melissa
>  
>  ----- Original Message ----- 
>  From: "Alex Ionescu" <ionucu(a)videotron.ca>
>  To: "ReactOS Development List" <ros-dev(a)reactos.org>
>  Sent: Sunday, June 04, 2006 13:23
>  Subject: Re: [ros-dev] Policy question
>  
> >   Myria wrote:
> > >   Should ReactOS copy unnecessary restrictions that
> > > Windows has? 
> >  You're not an NT designer. Just because you find something "unnecessary"
> >  doesn't mean it is. Have you emailed anyone at Microsoft to verify your
> >  theory, before potentially creating a security hole?
> >
> > >>> The example I'm thinking of is NtSetLdtEntries.  In Windows NT (and
> > > currently ReactOS as well), this function will not let you create an 
>  LDT
> > >   entry
> > > whose limit is above the user/kernel barrier.
> > >  This restriction sounds
> > >  like it was made with security in mind, but it doesn't affect security. 
> >  Then I would venture to guess that the internationally recognized and
> >  distinguished engineers, professors and developers originally assigned
> >  with the NT project didn't think of security.
> >
> > >   The
> > >  processor's page table will already block access to kernel memory no 
> > >  matter
> > >  what selector you use.  After all, the default user CS and DS already 
> > >  have a
> > >  limit of FFFFFFFF.
> > >
> > >  Should such a problem be fixed? 
> >  We don't even know if it's a problem yet. As of now, it's an assumption.
> >
> > >>> Fireball said "no, unless some 3rd party app or driver depends on 
> them" 
> > >   when
> > >  I asked about whether such restrictions should be copied.  Pretty much 
> > >  the
> > >  only thing using NtSetLdtEntries is NTVDM, and this restriction already
> > >  causes some DOS programs to break that would otherwise work.  (Such 
> > >  programs
> > >  are usually setting selectors that wrap the address space.) 
> >  The decision was made a long time ago not to export additional APIs or
> >  provide extra functionality which would cause programs to work on
> >  ReactOS but not Windows. This creates a dangerous slippery slope. Not
> >  being compatible doesn't only mean "not having all the features", it
> >  also means "having more features". Once ROS DLLs/programs/3rd-party
> >  applications start depending on ReactOS, you break compatibility. You
> >  also start breaking the DDK license.
> >
> >  But even before getting to this line of thought, I ask again. Have you
> >  verified this allegation?
> >
> > > >  >
> > > > Melissa 
> > >  
> >  Best regards,
> >  Alex Ionescu
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
      Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

[Alex Ionescu]

Melissa,

I have forwarded your question to David Cutler.

Best regards,
Alex Ionescu

Myria wrote:
>   Should ReactOS copy unnecessary restrictions that
> Windows has?
>  
>  The example I'm thinking of is NtSetLdtEntries.  In Windows NT (and 
>  currently ReactOS as well), this function will not let you create an LDT 
>  entry whose limit is above the user/kernel barrier.  This restriction sounds 
>  like it was made with security in mind, but it doesn't affect security.  The 
>  processor's page table will already block access to kernel memory no matter 
>  what selector you use.  After all, the default user CS and DS already have a 
>  limit of FFFFFFFF.
>  
>  Should such a problem be fixed?
>  
>  Fireball said "no, unless some 3rd party app or driver depends on them" when 
>  I asked about whether such restrictions should be copied.  Pretty much the 
>  only thing using NtSetLdtEntries is NTVDM, and this restriction already 
>  causes some DOS programs to break that would otherwise work.  (Such programs 
>  are usually setting selectors that wrap the address space.)
>  
>  Melissa 
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Alex Ionescu]

Alex Ionescu wrote:
>   Melissa,
>  
>  I have forwarded your question to David Cutler.
>  
>  Best regards,
>  Alex Ionescu 
(or someone else in the NT team, I used the name as a catch-all. If you
have any other questions you need to ask, you can use
http://blogs.msdn.com/erick/default.aspx to submit any non-IP/NDA/DRM
inquiries).

I will also not share the information if it cannot be shared with you.
At best, you may have found an interesting bug, at worse, some internal
behavior which cannot be made public.

Best regards,
Alex Ionescu