That is very true.
I do think that there's more depth to it than that.
For example, dealing with it on the end of the terminal will probably break compatibility, and dealing with it on the app end will require every single dev to start sanitizing this.
The challenges are real.
How many programmers does it take to filter out 36 characters? You may think this is an opening to a joke, but it’s not.
How many programmers does it take to filter out 36 characters? You may think this is an opening to a joke, but it’s not.
It takes a special kind of person to name a company after their own body part. Fortunately the Microsoft Security Response Center doesn’t seem to have inherited that kind of mentality, because when I have reported not a bug but a feature as a vulnerability - they accepted it.
cross-posted from: https://infosec.pub/post/5707149
> I talk about a report I've made to MSRC in the beginning of the year regarding vscode. > > It's a bit different. There's no in depth technical stuff, because I basically just reported the feature, not a bug.
It takes a special kind of person to name a company after their own body part. Fortunately the Microsoft Security Response Center doesn’t seem to have inherited that kind of mentality, because when I have reported not a bug but a feature as a vulnerability - they accepted it.
I talk about a report I've made to MSRC in the beginning of the year regarding vscode.
It's a bit different. There's no in depth technical stuff, because I basically just reported the feature, not a bug.
It was the year of the Linux desktop 1978. Old yellowed computers were not yet old, nor yellowed. Digital Equipment Corporation released the first popular terminal to support a standardized in-band encoding for control functions, the VT100.
cross-posted from: https://infosec.pub/post/2466014
> This is my first write-up, on a vulnerability I discovered in iTerm2 (RCE). Would love to hear opinions on this. I tried to make the writing engaging.
It was the year of the Linux desktop 1978. Old yellowed computers were not yet old, nor yellowed. Digital Equipment Corporation released the first popular terminal to support a standardized in-band encoding for control functions, the VT100.
cross-posted from: https://infosec.pub/post/2466014
> This is my first write-up, on a vulnerability I discovered in iTerm2 (RCE). Would love to hear opinions on this. I tried to make the writing engaging.
It was the year of the Linux desktop 1978. Old yellowed computers were not yet old, nor yellowed. Digital Equipment Corporation released the first popular terminal to support a standardized in-band encoding for control functions, the VT100.
cross-posted from: https://infosec.pub/post/2466014
> This is my first write-up, on a vulnerability I discovered in iTerm2 (RCE). Would love to hear opinions on this. I tried to make the writing engaging.
It was the year of the Linux desktop 1978. Old yellowed computers were not yet old, nor yellowed. Digital Equipment Corporation released the first popular terminal to support a standardized in-band encoding for control functions, the VT100.
cross-posted from: https://infosec.pub/post/2466014
> This is my first write-up, on a vulnerability I discovered in iTerm2 (RCE). Would love to hear opinions on this. I tried to make the writing engaging.
It was the year of the Linux desktop 1978. Old yellowed computers were not yet old, nor yellowed. Digital Equipment Corporation released the first popular terminal to support a standardized in-band encoding for control functions, the VT100.
cross-posted from: https://infosec.pub/post/2466014
> This is my first write-up, on a vulnerability I discovered in iTerm2 (RCE). Would love to hear opinions on this. I tried to make the writing engaging.
It was the year of the Linux desktop 1978. Old yellowed computers were not yet old, nor yellowed. Digital Equipment Corporation released the first popular terminal to support a standardized in-band encoding for control functions, the VT100.
This is my first write-up, on a vulnerability I discovered in iTerm2 (RCE). Would love to hear opinions on this. I tried to make the writing engaging.
I think they're lacking explanation of what the data means.
This can be very nuanced, and dependent on your goals.
For example, in the context of fingerprinting, sometimes it's better to provide fake data instead of no data, because that itself can be a unique characteristic.
I feel like I'm a bit lacking when it comes to finding race condition vulnerabilities. Any tips on that?
Took them 5 years to fix a critical vulnerability.
Really shows their concern for security.