Re: [ros-dev] Policy question

[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