date:20160929

Re: XLookupString return inconsistent

2016-09-29 Thread martin f krafft

also sprach wetts...@gmail.com  [2016-09-12 18:01 +0200]:
> > And moments after clicking send, I realized this is really just hardcoding
> > US keyboard layout & ASCII encoding - Shift-2 is '@' and Ctrl-@ is '\0'.
> 
> Oh, yes.  And Ctrl+3-7 get mapped to 0x1b-0x1f, the control codes beyond
> Ctrl-Z.  Ctrl+8 becomes 0x7f, that is, ASCII DEL.  So the full ASCII
> range becomes available.  It does make sense, from a perspective of text
> terminals.

Hey guys, sorry for the late response to "my" thread.

So this makes sense from the perspective of text terminals, but we
are talking X.org here, aren't we? ;)

Long story short: do you see any chance in making this bit of
legacy (nostalgia?) code configurable, or remove it altogether?

Cheers,

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
quidquid latine dictum sit, altum viditur.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

some potential security issue for edid-decode

2016-09-29 Thread shirish शिरीष

Hi all,

First of all thank you all for the wonderful work you are during in
X.org and its components. I have been using x.org and it components
forever.

Please make sure to CC me in case anybody replies as I have turned off
general replies from the list as I'm already info. overloaded.

I have been looking at a tool called I-Nex. During course of things I
came across the following -

┌─[shirish@debian] - [~/games/I-Nex] - [10043]
└─[$] flawfinder -Q -c .

Flawfinder version 1.31, (C) 2001-2014 David A. Wheeler.
Number of rules (primarily dangerous function names) in C/C++ ruleset: 169
./JSON/i-nex-edid.c:137:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
static char name[4];
./JSON/i-nex-edid.c:153:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
const unsigned char empty[3] = { 0, 0, 0 };
./JSON/i-nex-edid.c:211:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
static char ret[128];
./JSON/i-nex-edid.c:241:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
static unsigned char name[53];
./JSON/i-nex-edid.c:1587:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
char buf[3];
./JSON/i-nex-edid.c:1621:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
char buf[3];
./JSON/i-nex-edid.c:1683:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
char buf[3];
./JSON/i-nex-edid.c:1776:  [2] (misc) open:
  Check when opening files - can an attacker redirect it (via symlinks),
  force the opening of special file type (e.g., device files), move things
  around to create a race condition, control its ancestors, or change its
  contents? (CWE-362).
if ((fd = open(argv[1], O_RDONLY)) == -1) {
./JSON/i-nex-edid.c:1783:  [2] (misc) open:
  Check when opening files - can an attacker redirect it (via symlinks),
  force the opening of special file type (e.g., device files), move things
  around to create a race condition, control its ancestors, or change its
  contents? (CWE-362).
if ((fd = open(argv[1], O_RDONLY)) == -1) {
./JSON/i-nex-edid.c:1787:  [2] (misc) open:
  Check when opening files - can an attacker redirect it (via symlinks),
  force the opening of special file type (e.g., device files), move things
  around to create a race condition, control its ancestors, or change its
  contents? (CWE-362).
if ((ofd = open(argv[2], O_WRONLY)) == -1) {
./JSON/i-nex-edid.c:319:  [1] (buffer) strncat:
  Easily used incorrectly (e.g., incorrectly computing the correct maximum
  size to add) (CWE-120). Consider strcat_s, strlcat, or automatically
  resizing strings.
strncat((char *)name, (char *)x + 5, 13);
./JSON/i-nex-edid.c:324:  [1] (buffer) strlen:
  Does not handle strings that are not \0-terminated; if given one it may
  perform an over-read (it could cause a crash if unprotected) (CWE-126).
  strlen((char *)name)));
./JSON/i-nex-edid.c:1521:  [1] (buffer) read:
  Check buffer boundaries if used in a loop including recursive loops
  (CWE-120, CWE-20).
i = read(fd, ret + len, size - len);
./JSON/i-nex-edid.c:1576:  [1] (buffer) strlen:
  Does not handle strings that are not \0-terminated; if given one it may
  perform an over-read (it could cause a crash if unprotected) (CWE-126).
start = s + strlen(indentation);
./JSON/i-nex-edid.c:1735:  [1] (buffer) strlen:
  Does not handle strings that are not \0-terminated; if given one it may
  perform an over-read (it could cause a crash

Re: some potential security issue for edid-decode

2016-09-29 Thread Alan Coopersmith


In general, we'd prefer reports of security issues go to our security list
(which I've cc'ed) instead of our general discussion list, but in this case,
unless I'm missing something, in our code, these are just plain bugs, as
there's no trust or privilege boundary someone can exploit here.

If someone made that code setuid-root or used it to process input from an
untrusted source, then the situation might be different.

-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

On 09/29/16 07:48 AM, shirish शिरीष wrote:

Hi all,

First of all thank you all for the wonderful work you are during in
X.org and its components. I have been using x.org and it components
forever.

Please make sure to CC me in case anybody replies as I have turned off
general replies from the list as I'm already info. overloaded.

I have been looking at a tool called I-Nex. During course of things I
came across the following -

┌─[shirish@debian] - [~/games/I-Nex] - [10043]
└─[$] flawfinder -Q -c .

Flawfinder version 1.31, (C) 2001-2014 David A. Wheeler.
Number of rules (primarily dangerous function names) in C/C++ ruleset: 169
./JSON/i-nex-edid.c:137:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
static char name[4];
./JSON/i-nex-edid.c:153:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
const unsigned char empty[3] = { 0, 0, 0 };
./JSON/i-nex-edid.c:211:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
static char ret[128];
./JSON/i-nex-edid.c:241:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
static unsigned char name[53];
./JSON/i-nex-edid.c:1587:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
char buf[3];
./JSON/i-nex-edid.c:1621:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
char buf[3];
./JSON/i-nex-edid.c:1683:  [2] (buffer) char:
  Statically-sized arrays can be improperly restricted, leading to potential
  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
  functions that limit length, or ensure that the size is larger than the
  maximum possible length.
char buf[3];
./JSON/i-nex-edid.c:1776:  [2] (misc) open:
  Check when opening files - can an attacker redirect it (via symlinks),
  force the opening of special file type (e.g., device files), move things
  around to create a race condition, control its ancestors, or change its
  contents? (CWE-362).
if ((fd = open(argv[1], O_RDONLY)) == -1) {
./JSON/i-nex-edid.c:1783:  [2] (misc) open:
  Check when opening files - can an attacker redirect it (via symlinks),
  force the opening of special file type (e.g., device files), move things
  around to create a race condition, control its ancestors, or change its
  contents? (CWE-362).
if ((fd = open(argv[1], O_RDONLY)) == -1) {
./JSON/i-nex-edid.c:1787:  [2] (misc) open:
  Check when opening files - can an attacker redirect it (via symlinks),
  force the opening of special file type (e.g., device files), move things
  around to create a race condition, control its ancestors, or change its
  contents? (CWE-362).
if ((ofd = open(argv[2], O_WRONLY)) == -1) {
./JSON/i-nex-edid.c:319:  [1] (buffer) strncat:
  Easily used incorrectly (e.g., incorrectly computing the correct maximum
  size to add) (CWE-120). Consider strcat_s, strlcat, or automatically
  resizing strings.
strncat((char *)name, (char *)x + 5, 13);
./JSON/i-nex-edid.c:324:  [1] (buffer) strlen:
  Does not handle strings that are not \0-terminated; if given one it may
  perform an over-read (it could cause a crash if unprotected) (CWE-126).
  st

Re: XLookupString return inconsistent

2016-09-29 Thread wettstae

> Long story short: do you see any chance in making this bit of
> legacy (nostalgia?) code configurable, or remove it altogether?

I do not know, but I do not see the benefit of doing that.  It certainly
would not fix your problem, which I still think is hardware.

Andreas



___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: XLookupString return inconsistent

2016-09-29 Thread martin f krafft

also sprach wetts...@gmail.com  [2016-09-29 21:00 +0200]:
> I do not know, but I do not see the benefit of doing that.  It
> certainly would not fix your problem, which I still think is
> hardware.

I think you are right. I just noticed that this only happens with my
USB keyboards, not with the Thinkpad built-in keyboard.

So there's no way to work around this?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"die menschen drängen sich zum lichte, nicht um besser zu sehen,
 sondern um besser zu glänzen."
 - friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: some potential security issue for edid-decode

2016-09-29 Thread Seth Arnold

On Thu, Sep 29, 2016 at 09:14:52AM -0700, Alan Coopersmith wrote:
> On 09/29/16 07:48 AM, shirish शिरीष wrote:
> >Flawfinder version 1.31, (C) 2001-2014 David A. Wheeler.
> >Number of rules (primarily dangerous function names) in C/C++ ruleset: 169
> >./JSON/i-nex-edid.c:137:  [2] (buffer) char:
> >  Statically-sized arrays can be improperly restricted, leading to potential
> >  overflows or other issues (CWE-119:CWE-120). Perform bounds checking, use
> >  functions that limit length, or ensure that the size is larger than the
> >  maximum possible length.
> >static char name[4];
[...]

If all this tool is doing is reporting static allocations and C functions
that can be misused it doesn't seem particularly useful. Static array
allocations are a fact of programming in C, and very nearly every API is
unsafe when used incorrectly. That's just what C is. It might be nice to
guide an audit but on its own it doesn't seem too revealing.

I strongly recommend cppcheck instead. It's not perfect, but it is
surprisingly good.

Thanks

signature.asc
Description: PGP signature
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xrandr: cannot find output 0x95

2016-09-29 Thread Thomas Lübking


On Tue, Sep 27, 2016 at 11:00:13PM -0400, John Lewis wrote:


xrandr --output DisplayPort-3 --off
...
DisplayPort-3 disconnected


No idea why arandr wants to configure a disconnected output, but this is
most likely the cause. Seems an arandr bug.

Cheers,
Thomas
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xrandr: cannot find output 0x95

2016-09-29 Thread John Lewis

When I run xrandr --output 0x95 --off DVI-0 turns off.

john@thunderguard:~/.screenlayout$ xrandr --output 0x95 --off

john@thunderguard:~/.screenlayout$ xrandr --current
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
DisplayPort-3 disconnected
HDMI-3 connected 1920x1080+0+0 510mm x 287mm
   1920x1080 60.00*+  50.0059.94 
   1920x1080i60.0050.0059.94 
   1680x1050 59.88 
   1280x1024 60.02 
   1440x900  59.90 
   1280x800  59.91 
   1152x864  75.00 
   1280x720  59.9760.0050.0059.94 
   1024x768  70.0760.00 
   800x600   60.3256.25 
   720x576   50.00 
   720x480   60.0059.94 
   640x480   66.6760.0059.94 
   720x400   70.08 
DVI-0 connected
   1920x1080 60.00 +
   1280x1024 75.0260.02 
   1280x960  60.00 
   1280x800  59.91 
   1152x864  75.00 
   1280x720  59.97 
   1024x768  75.0870.0760.00 
   832x624   74.55 
   800x600   72.1975.0060.3256.25 
   640x480   75.0072.8166.6760.00 
   720x400   70.08 

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: XLookupString return inconsistent

some potential security issue for edid-decode

Re: some potential security issue for edid-decode

Re: XLookupString return inconsistent

Re: XLookupString return inconsistent

Re: some potential security issue for edid-decode

Re: xrandr: cannot find output 0x95

Re: xrandr: cannot find output 0x95

8 matches

Site Navigation

Mail list logo

Footer information