Кратко

  • RFC 1408 задал для опции Telnet 36 соответствие VAR=0, VALUE=1; RFC 1571 сообщил, что эталонная реализация BSD использовала эти два смысла наоборот.
  • RFC 1571 пытался определить словарь удалённой стороны по невозможным маркерам, позиции, пустым полям, количеству и известным именам. Некоторые последовательности не давали однозначного ответа.
  • RFC 1572 сохранил опубликованное соответствие, но перенёс его в новую опцию 39 NEW-ENVIRON. Распознанная переменная всё равно оставалась входом для локального решения сервера.

Один байт разделил не данные, а способы чтения

RFC 1408 был опубликован в январе 1993 года. Опция ENVIRON под номером 36 передавала сведения об окружении при установлении соединения Telnet. Команды подпереговоров получили значения IS=0, SEND=1, INFO=2; внутренние разделители — VAR=0, VALUE=1, ESC=2, USERVAR=3.

Разделители сохраняли различия, которые обычная таблица ключей стирает. Если после имени не шёл VALUE, переменная считалась неопределённой. Если VALUE сразу сменялся следующим типом или концом, переменная была определена, но пуста. Управляющий октет внутри имени или значения требовал экранирования. Пустое окружение являлось законным ответом.

Поэтому перестановка нуля и единицы меняла структуру, а не только термин. Один парсер видел начало имени там, где другой видел начало значения.

В январе 1994 года RFC 1571 описал происхождение расхождения. Определения VAR и VALUE в RFC 1408 были обратны определениям BSD. Причём BSD назывался эталонной реализацией, которую RFC должен был документировать, и основой многих существовавших реализаций.

Это утверждение самого меморандума, не независимая перепись установок. Оно не даёт долей и названий систем. Оно устанавливает необходимый минимум: у опции 36 существовало две исторические интерпретации, а её номер не сообщал, какая из них работала на другом конце.

Оболочка для сведений, чужих самому Telnet

Операционным системам требовалось переносить на удалённый узел стартовую информацию. Создание отдельной опции под каждое новое поле заставило бы Telnet понимать всё больше локальных деталей. ENVIRON предложил общий контейнер.

Известными считались USER, JOB, ACCT, PRINTER, SYSTEMTYPE и DISPLAY. Произвольные пользовательские пары помечались USERVAR. Метка сообщала класс происхождения, но не удостоверяла значение. RFC допускал, что осторожная реализация будет одинаково недоверчива к обоим классам; столкновение известного и пользовательского имени оставалось делом конкретной программы.

По умолчанию обмен был выключен: WONT ENVIRON, DONT ENVIRON. Готовность отправлять объявлялась WILL, готовность принимать — DO. Только сторона DO могла начать SEND; только сторона WILL могла ответить IS либо позже самопроизвольно прислать изменение INFO.

Так протокол разделял согласие и событие. WILL не был фактом отправки. SEND не означал, что переменная определена. IS относился к начальному ответу, INFO — к последующим изменениям. Ни один кадр не доказывал, что получатель применил сведения.

Близость к входу требовала локальной осторожности

Многие системы передавали окружение только при создании процесса, поэтому сведения обычно требовались в начале соединения, до входа пользователя. Ранний момент увеличивал возможное влияние, но не авторитет отправителя.

RFC 1408 прямо разрешал серверу не помещать полученные переменные в окружение. Неизвестное имя можно было проигнорировать. USER или ACCT могли участвовать в выборе учётной записи, но не попасть в окружение процесса. Значение из более точного источника могло заменить присланное.

Если Terminal-Type уже определил тип терминала, сервер вправе был отвергнуть USERVAR TERM=xterm. Для противоречия между DISPLAY и X-Display-Location документ предложил другую политику: выбирать более позднее сообщение. В обоих случаях общая грамматика доводила конкурирующие входы до точки решения, но решение оставалось у принимающей стороны.

USER означал желаемое имя учётной записи, а не аутентифицированного человека. Для PRINTER ещё не существовало стандартного сетевого формата имени; поле не подтверждало ни доступность, ни печать. DISPLAY не доказывал X-соединение или показ окна.

Раздел безопасности предупреждал об установке переменных до входа. Если поле влияло на программу аутентификации, злоумышленник мог обойти или скомпрометировать её. Это не сообщение о конкретном инциденте. Это граница между удалённым предложением и локальным правом придать ему действие.

RFC 1571 искал словарь в нарушениях грамматики

В старой опции не было номера версии синтаксиса. Оставалось изучать форму сообщения.

В SEND разрешались лишь VAR и USERVAR. Если клиент встречал маркер, который его словарь называл VALUE, сервер, вероятно, использовал обратный порядок. С этого места клиент должен был перевернуть разбор остатка и формирование ответа IS или INFO. Если ни нуля, ни единицы не было, наблюдения отсутствовали, и предписывалось предположить опубликованный порядок.

Для сервера сообщения IS и INFO были сложнее: значения в них законны. Немедленный VAR указывал на порядок RFC, немедленный VALUE — на обратный. Если первым был USERVAR, следующий маркер мог легально обозначать разные вещи. Тогда искали два одинаковых разделителя подряд, пустые разделители, сравнивали количества и проверяли строки на похожесть на известные имена.

Эвристики не удостоверяли отправителя. Они классифицировали, какой исторический синтаксис лучше объясняет байты. Невозможная форма давала сильную границу; узнаваемое имя — лишь вероятность. Если тесты не помогали, сервер принимал порядок RFC по умолчанию. Такая политика не превращала неизвестность в наблюдавшийся факт.

Если сохранить только очищенную пару, исчезнет основание решения. Для повторной проверки нужны исходные байты, номер опции, направление, состояние переговоров, версия декодера, выбранный словарь, сработавшее правило и остаточная неопределённость.

Новый номер отделил будущее от наследия

RFC 1572 оставил VAR=0, VALUE=1, но поместил грамматику под новый номер 39 — NEW-ENVIRON. Документ объяснял, что новая опция позволяет реализациям взаимодействовать без двусмысленности.

Повторное объявление таблицы для номера 36 не показывало бы, какой старый бинарный файл находится у собеседника. Переговоры о 39 одновременно выбирали новую метку и единственный словарь. Исправление не переписывало прошлое; оно создавало минимальный детерминированный вход в будущее.

В действующем реестре опций Telnet IANA остались обе записи: 36 — Environment Option из RFC 1408, 39 — New Environment Option из RFC 1572. Реестр сохраняет расхождение как историю. Он не подтверждает реализацию, успешное согласование, состояние процесса или результат.

NEW-ENVIRON также оставался выключенным по умолчанию, согласовывался по направлениям и не отменял локальной проверки. Общая сторона определяла чтение провода; сервер определял дальнейшее действие.

Декодирование находилось в середине доказательства

Полная лестница различает публикацию назначения, словарь отправителя, исходные октеты, разбор получателя, выбранную эвристику, кандидатную пару, класс источника, локальную политику, создание процесса, наблюдение приложения и внешний эффект.

RFC не перепрограммировал BSD. Согласие не доказывало отправку. USER не аутентифицировал личность. Принятие не доказывало наследование процессом. Окружение не доказывало исполнение. Каждому переходу требовалась отдельная запись.

Источники

Источники подтверждают грамматику, современное конфликту описание BSD, эвристики, новую опцию и реестр. Они не подтверждают конкретную реализацию, распространённость, атаку, личность, разрешённый вход, применённое окружение, исполнение команды или нынешний риск.