Re: bug report

Re: bug report

[Asad Ali]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

Hi Team,

Is there any update on this ? I'm hoping to receive a reward for the
reported bug.

Waiting for your response.

On Fri, Dec 30, 2022 at 5:46 AM Asad Ali <asadali.282821@gmail.com> wrote:

> Hey Team,
>
>
>
> I'm a penetration tester and bug bounty hunter. I have found a potential
> vulnerability in the site. Please review the report below.
>
>
>
> Vulnerability: Broken Authentication & Session Management
> We have observed that when we change "password" from one browser in place
> of session expiration from another browser it just updates the password
> from another browser and the old session gets updated without being logged
> out. The flows goes like this:
> Broken Authentication and Session Management > Failure to Invalidate
> Session > On Password Change
> Steps:
>
> 1- Login from two browsers at a time [From Chrome browser and from Mozilla
> Firefox].
>
> 2- Change password in settings from chrome browser.
>
> 3- Now Check Mozilla Firefox.
>
> 4- Your Session got "updated" in place of expiration.
>
>
>
>
> Same goes with when using two different computer systems.
>
> 1- Login from two computers at a time
>
> 2- Change password in settings from computer A.
>
> 3- Now Check computer B.
> 4- Your Session got "updated" in place of expiration.
>
> Recommendations: If Session is Updating from one Browser/Computer so other
> should expire first to renew session after login.
>
>
>
> If you require any additional information, please let me know. I'll be
> waiting to hear from your side regarding the report and bounty.
>

Re: bug report

[Brian Inglis]

On 2023-09-06 16:20, Asad Ali via Cygwin wrote:
> On Fri, Dec 30, 2022 at 5:46 AM Asad Ali <asadali.282821@gmail.com> wrote:
>> I'm a penetration tester and bug bounty hunter. I have found a potential
>> vulnerability in the site. Please review the report below.
> Is there any update on this ? I'm hoping to receive a reward for the
> reported bug. Waiting for your response.
Cygwin site does not require logins, maybe you have been phished?
Cygwin is a volunteer project and does not offer any bounties.
Your report does not provide a Simple Test Case, reproducible step by step 
process, attached cygcheck output, or show any signs of being related to this 
project, as it does not provide those browsers.
Please give yourself 2 cents for your report.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: Bug Report

[Bill Stewart]

On Tue, Feb 8, 2022 at 3:02 PM julie77793 wrote:

Cygwin doesn't create an environment variable in bash to indicate that the
> platform is Cygwin under Windows.
>

FYI, as a point of decorum: The subject line of this thread is rather
undiplomatic.

(Bug usually means "software should do X but fails in some way," not
"please add feature X.")

Recommended reading: How to ask questions the smart way[1]

[1] http://www.catb.org/~esr/faqs/smart-questions.html

Bill

Re: Bug Report

[Ernie Rael]

On 2/8/22 2:01 PM, julie77793@gmail.com wrote:
> Cygwin doesn't create an environment variable in bash to indicate that the
> platform is Cygwin under Windows.
>
> This causes compatibility problems when running various tools. Most of my
> issues have been with Python tools running Windows Python.
>
> I have been addressing this issue by grepping PATH for cygdrive which
> doesn't seem like a very good approach.
>
> Both msys2 and mingw solve this issue by setting the MSYSTEM environment
> variable which lets tools check that OS=Windows_NT and MSYSTEM=MSYS
>
> Please add some way of identifying that programs are running under Cygwin.
>
And of course there's

    $ uname -o
    Cygwin

-ernie

Bug Report

[julie77793]

Cygwin doesn't create an environment variable in bash to indicate that the
platform is Cygwin under Windows.

This causes compatibility problems when running various tools. Most of my
issues have been with Python tools running Windows Python.

I have been addressing this issue by grepping PATH for cygdrive which
doesn't seem like a very good approach.

Both msys2 and mingw solve this issue by setting the MSYSTEM environment
variable which lets tools check that OS=Windows_NT and MSYSTEM=MSYS

Please add some way of identifying that programs are running under Cygwin.

Re: Bug report

[Igor Pechtchanski]

On Mon, 5 May 2003, Igor Pechtchanski wrote:

> On 5 May 2003, Kern Sibbald wrote:
> [snip]
> > > Did you try running the program from the command line in a
> > > LocalSystem-owned shell?
> >
> > I ran it in an rxvt shell under my id and it does not crash.
> > Tell me how to get a LocalSystem owned shell and I will try
> > it.  This is XP Home, so I don't have access to a lot of the
> > XP security dialogs.
>
> "at <time> /interactive c:\cygwin\bin\bash.exe -i --login"
> (<time> should be current time however long you're willing to wait, at
                                ^ plus

> least one minute).  "at /?" for help.
> [Note, this works on Win2k, don't know about XP Home].

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Knowledge is an unending adventure at the edge of uncertainty.
  -- Leto II


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug report

[Igor Pechtchanski]

On 5 May 2003, Kern Sibbald wrote:

> Hello,
>
> On Mon, 2003-05-05 at 18:38, Igor Pechtchanski wrote:
> > On 5 May 2003, Kern Sibbald wrote:
> >
> > > I guess you guys (and gal) really don't want bug
> > > reports because it is not at all obvious where
> > > to send them.
> >
> > This is the right place.
>
> Great.
>
> > > Anyway here is one:
> > >
> > > Running WinXP Home version.
> > >
> > > Using Cygwin 1.3.20
> > >
> > > When running my program with LocalSystem userid
> > > as a service, doing a pthread_kill(thread_id, SIGUSR2)
> > > causes some sort of memory fault referencing memory at 0x3a
> > > (or something like that because the program disappears
> > > poof).
> > >
> > > Running as a normal user works fine.
> >
> > What's the exact error message (I assume you get a popup box)?
>
> No, I get absolutely nothing. Poof and it is gone, well, the
> service manager knows it went away but not why.
>
> A friend ran the program on Win2K and he got:
>
>       Instruction at 0x0041276a referenced memory at 0x3c
>
> That appears to be somewhere in the cygwin1.dll.

Try checking the "Allow service to interact with the desktop" box, and you
should see the error popup on your system too.

> > Is there a stacktrace file generated?
>
> If it is, I don't know where the system put it.

The system should put it in the directory from which the program is run.

> >   Did you try setting
> > "error_start:c:/cygwin/bin/dumper.exe" in your CYGWIN environment
> > variable?
>
> No, if you can tell me how to set the environment variable for
> a service, I'll try it, but since it is a service, I am unlikely
> to get any output.

"cygrunsrv --help", or "man cygrunsrv", or see /bin/ssh-host-config for an
example.  You might also need the "Allow service to interact with desktop"
bit.

> > Did you try running the program from the command line in a
> > LocalSystem-owned shell?
>
> I ran it in an rxvt shell under my id and it does not crash.
> Tell me how to get a LocalSystem owned shell and I will try
> it.  This is XP Home, so I don't have access to a lot of the
> XP security dialogs.

"at <time> /interactive c:\cygwin\bin\bash.exe -i --login"
(<time> should be current time however long you're willing to wait, at
least one minute).  "at /?" for help.
[Note, this works on Win2k, don't know about XP Home].

> > Can you provide a simple testcase that
> > reproduces your problem?
>
> Probably not as my program is some 65K+ lines of code.

You could try a simple program that calls the offending function (after
creating some threads, most likely), and see if the problem manifests...

> I've solved the problem for myself by doing the "signal"
> a different way, so it is not critical for me but it cost
> about 8 hours of debugging -- primarily due to the fact that
> it seems to be dependent on whether or not it is a service.
>
> Best regards,
> Kern

It's most likely dependent on the value of your CYGWIN variable or some
permissions (as the service runs as LocalSystem).  Trying the program out
from a LocalSystem-owned window (see above) should give you some idea of
what's at fault.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Knowledge is an unending adventure at the edge of uncertainty.
  -- Leto II


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug report

[Kern Sibbald]

Hello,

On Mon, 2003-05-05 at 18:38, Igor Pechtchanski wrote:
> On 5 May 2003, Kern Sibbald wrote:
> 
> > I guess you guys (and gal) really don't want bug
> > reports because it is not at all obvious where
> > to send them.
> 
> This is the right place.

Great.

> 
> > Anyway here is one:
> >
> > Running WinXP Home version.
> >
> > Using Cygwin 1.3.20
> >
> > When running my program with LocalSystem userid
> > as a service, doing a pthread_kill(thread_id, SIGUSR2)
> > causes some sort of memory fault referencing memory at 0x3a
> > (or something like that because the program disappears
> > poof).
> >
> > Running as a normal user works fine.
> 
> What's the exact error message (I assume you get a popup box)?

No, I get absolutely nothing. Poof and it is gone, well, the
service manager knows it went away but not why.

A friend ran the program on Win2K and he got:

      Instruction at 0x0041276a referenced memory at 0x3c

That appears to be somewhere in the cygwin1.dll.

> Is there a stacktrace file generated?

If it is, I don't know where the system put it.

>   Did you try setting
> "error_start:c:/cygwin/bin/dumper.exe" in your CYGWIN environment
> variable?  

No, if you can tell me how to set the environment variable for
a service, I'll try it, but since it is a service, I am unlikely
to get any output.

> Did you try running the program from the command line in a
> LocalSystem-owned shell?  

I ran it in an rxvt shell under my id and it does not crash.
Tell me how to get a LocalSystem owned shell and I will try
it.  This is XP Home, so I don't have access to a lot of the
XP security dialogs.

> Can you provide a simple testcase that
> reproduces your problem?

Probably not as my program is some 65K+ lines of code.

I've solved the problem for myself by doing the "signal"
a different way, so it is not critical for me but it cost
about 8 hours of debugging -- primarily due to the fact that
it seems to be dependent on whether or not it is a service.

Best regards,

Kern


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug report

[Christopher Faylor]

On Mon, May 05, 2003 at 06:21:24PM +0200, Kern Sibbald wrote:
>I guess you guys (and gal) really don't want bug reports because it is
>not at all obvious where to send them.

From http://cygwin.com/lists.html - 

"cygwin: a high volume list for discussion of just about all things
Cygwin-related.  If you have questions about how to use Cygwin, or if
you have cygwin-specific (see above) questions, bugs, or observations
about the UNIX tools (bash, gcc, make, etc.) that come with Cygwin, this
is the list for you..."

The 'bugs' part of the above sentence would make it pretty obvious where
to send bug reports.

>Anyway here is one:
>
>Running WinXP Home version.
>
>Using Cygwin 1.3.20
>
>When running my program with LocalSystem userid as a service, doing a
>pthread_kill(thread_id, SIGUSR2) causes some sort of memory fault
>referencing memory at 0x3a (or something like that because the program
>disappears poof).
>
>Running as a normal user works fine.

The words at http://cygwin.com/bugs.html might help you craft a bug
report which actually would stand a chance of being looked at.  This
message is too vague for anyone to be able to help you.

cgf
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sourceware.org
and be permanently blocked from mailing lists at sources.redhat.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug report

[Igor Pechtchanski]

On 5 May 2003, Kern Sibbald wrote:

> I guess you guys (and gal) really don't want bug
> reports because it is not at all obvious where
> to send them.

This is the right place.

> Anyway here is one:
>
> Running WinXP Home version.
>
> Using Cygwin 1.3.20
>
> When running my program with LocalSystem userid
> as a service, doing a pthread_kill(thread_id, SIGUSR2)
> causes some sort of memory fault referencing memory at 0x3a
> (or something like that because the program disappears
> poof).
>
> Running as a normal user works fine.

What's the exact error message (I assume you get a popup box)?
Is there a stacktrace file generated?  Did you try setting
"error_start:c:/cygwin/bin/dumper.exe" in your CYGWIN environment
variable?  Did you try running the program from the command line in a
LocalSystem-owned shell?  Can you provide a simple testcase that
reproduces your problem?
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Knowledge is an unending adventure at the edge of uncertainty.
  -- Leto II


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Bug report

[Kern Sibbald]

I guess you guys (and gal) really don't want bug
reports because it is not at all obvious where
to send them.  

Anyway here is one:

Running WinXP Home version.

Using Cygwin 1.3.20

When running my program with LocalSystem userid
as a service, doing a pthread_kill(thread_id, SIGUSR2) 
causes some sort of memory fault referencing memory at 0x3a 
(or something like that because the program disappears
poof).

Running as a normal user works fine.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Bug report

[David L Wiltshire]

Cygwin DLL 1.3.2

I just installed this on Win 98 SE box. The paste button on the bash
window does not function (although the other buttons appear to work
fine). If the clipboard is empty pushing on the paste button registers
an error message "Clipboard empty" but if there is something is on the
clipboard there is simply no effect.

Best regards,

David Wiltshire

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Bug Report

[Christopher G. Faylor]

In article <199807010655.IAA00527.cygnus.gnu-win32@surgery1.best.ms.philips.com>,
Ronald Pijnacker <Ronald.Pijnacker@best.ms.philips.com> wrote:
>....
>> To fix the most serious problems:
>>   Please, _READ_ the IMPORTANT UPGRADE NOTICE at the end of this note.
>>   Please, ensure that there is only _ONE_ cygwinb19.dll.
>>   Please, ensure that _ALL_ b18 binaries have been removed.
>>   Please, _USE_ the Searchable Mail Archives.
>....
>
>Wouldn't it be about time to release a new (or at least updated)
>version of the cygwin stuff? This would alow newcomers to start
>without having to upgrade their newly installed distrubution before
>they can do something useful. It would also eliminate the necessity
>for Earnie to keep on having to type `_READ_ the IMPORTANT UPGRADE
>NOTICE' etc. every time somebody asks a question about why something
>doesn't work.

You're right.  We'll probably be releasing a new version sometime after
Geoffrey returns from vacation.
-- 
cgf@cygnus.com             "Everything has a boolean value, if you stand
http://www.cygnus.com/      far enough away from it."  -- Galena Alyson Canada
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug Report

[Ronald Pijnacker]

....
> To fix the most serious problems:
>   Please, _READ_ the IMPORTANT UPGRADE NOTICE at the end of this note.
>   Please, ensure that there is only _ONE_ cygwinb19.dll.
>   Please, ensure that _ALL_ b18 binaries have been removed.
>   Please, _USE_ the Searchable Mail Archives.
....

Wouldn't it be about time to release a new (or at least updated)
version of the cygwin stuff? This would alow newcomers to start
without having to upgrade their newly installed distrubution before
they can do something useful. It would also eliminate the necessity
for Earnie to keep on having to type `_READ_ the IMPORTANT UPGRADE
NOTICE' etc. every time somebody asks a question about why something
doesn't work.

Ronald.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

bug report

[p.a.c.tavares]

The following code works fine in a HP system (using gcc 2.7.2), calling 
the correct "Column" contructor with the right arguments

int Table::init(int line,int col,double fill_value)
{
   n_lines = line;
   n_cols = col;
   if (pt) delete [] pt;
   pt = new Column[col](line,fill_value);
   if (pt == NULL) return 1;
   return 0;
}

However under cygwin, in spite of compiling fine it calls (according 
to gdb) the correct column constructor "Column::Column(int,double) but all 
the arguments show up as 0 (including the int which results in a lenght 0 
column being created). The form of this contructor is I believe 
irrelevant but here it is anyway. A check of the value of 'size' in the 
first line of the function tells that size=0 (when it was called with a 
positive number by Table::init(int,double),

Column::Column(int size,double fill_value)
{
	len = size;
	val = new float [len];
	while (size > 0) val[--size] = fill_value;
}


I am using gcc in a win95 system, 486 with 16Mb. the options of the 
compiler are -gstabs+ and a -I entry. The libraries are, -lstdc++ -lg++ 
-lm -lpact (the last being my own library)

----------------------------------------------------------------------------
Pedro A.C. Tavares <p.tavares@strath.ac.uk>

Superconducting Devices Group         Tel: +44-141-548 3151
Dept. of Physics & Applied Physics    Fax: +44-141-552 7143
University of Strathclyde             For PGP public key: "finger
Glasgow, UK                               pedro_t@zebedee.phys.strath.ac.uk"
----------------------------------------------------------------------------
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: bug report

[Sean McNeil]

I don't know if anyone has addressed this reported problem, but apparantly the stream
I/O routines are following the rule of assuming files are text unless fopen has the "b"
in the mode.  The posted code works just fine when opened with "wb" and "rb".
This appears to be consistent with what I read in the man pages regarding fopen.
This is not a bug, then, but the expected behaviour.

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: bug report

[Sergey Okhapkin]

Andres Takach wrote:
> 
> There seems to be a problem in the read() (getc etc.) when
> reading binary files. A character 1A can confuse the read
> to think that it has found the end of file.
>   fp = fopen("temp","w");
> 
>   fp = fopen("temp","r");

You should open binary files with "wb"/"rb" mode flags.

-- 
Sergey Okhapkin
Moscow, Russia
Looking for a job.


-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

bug report

[Andres Takach]

There seems to be a problem in the read() (getc etc.) when
reading binary files. A character 1A can confuse the read
to think that it has found the end of file.

This problem also happens when using the gnu-win92 "od" program.
In fact it also happens on the perl implementation for win 95/NT.
The perl problem happens on even NT machines. 

I have included below a simple c program that exposes the problem.

Andres Takach


#include <stdio.h>
#include <stdlib.h>

/* this program illustrates the fact that if the character 1A is
  present in a binary file, getc() will return an EOF at that point
  (same can be said about read() etc.)  The output of this program
  should be 13 (13 chars in file "temp") but instead it is 2.
  Program "od" will also quit early and same can be said about
  perl for windows 95/NT.
*/

main(){
  FILE *fp;
  int ch;
  int count = 0;
  int i;
  fp = fopen("temp","w");

/* Write two random chars to "temp"*/
  putc(255,fp); 
  putc('a',fp);
  
/* Write offending char 26 (Hex 1A) to "temp" */
  putc(26,fp);    

/* Write 10 more 'a's to file "temp"  and close file */
  for(i=0; i < 10; i++) putc('a',fp);  /* 10 more bytes */
  fclose(fp);

/* Attempt to count # of bytes in "temp" */
  fp = fopen("temp","r");
  while( getc(fp)!= EOF) count++;
  /* should be 13 bytes */
  printf("Number of bytes: %d\n",count);
}